Skip to main content
Use Firecrawl’s account endpoint when a person is present to sign in and approve access. The client receives short-lived, resource-bound tokens instead of your raw Firecrawl API key. For the complete choice between account OAuth, unattended API-key access, and keyless access, see Connect Firecrawl MCP.

​
Connect an interactive client

Point a compatible interactive client at:
If the client asks for an OAuth Client ID or Client Secret, leave both blank. Compatible clients identify themselves with Client ID Metadata Documents or Dynamic Client Registration. The client opens Firecrawl in your browser. Sign in, choose the team the connector should use, review the consent request, and approve access. Requests are billed to the selected team. Use the client-specific guides for ChatGPT and Claude, because their setup screens and workspace rules differ.

​
Cursor and VS Code redirect support

Use the account endpoint only when the installed client version can complete a remote OAuth flow. Firecrawl accepts HTTPS redirect URIs and loopback redirect URIs using http://localhost, http://127.0.0.1, or http://[::1]. For native HTTP loopback clients, the port may vary per run, but the registered host and path must match the requested redirect URI. If Cursor or VS Code cannot complete remote OAuth in the version you use, configure https://mcp.firecrawl.dev/v2/mcp with an Authorization: Bearer <FIRECRAWL_API_KEY> header instead. Keep the key in the client’s environment or secure-secret store; never put it in the URL.

​
Choose the hosted mode

For CI, servers, scripts, and other unattended clients, use https://mcp.firecrawl.dev/v2/mcp with an environment-variable-backed Authorization: Bearer <FIRECRAWL_API_KEY> header. Do not put an API key in a URL or project configuration file.

​
Manage a connection

To disconnect a client, open MCP in Firecrawl Settings and revoke the connection. Revocation makes its access and refresh tokens unusable; reconnect from the client to authorize again.

​
Compatibility during migration

  • Existing OAuth tokens explicitly bound to /v2/mcp continue working on /v2/mcp.
  • During the migration window, a compatible existing /v2/mcp token can also be accepted by /v2/mcp-oauth.
  • A new token issued for /v2/mcp-oauth is not accepted by /v2/mcp.
  • Tokens with a missing or ambiguous audience fail closed.
  • Existing legacy key-in-path MCP configurations continue working, but new configurations should use OAuth or a Bearer header.

​
Security properties

  • Access tokens expire after one hour.
  • Refresh tokens rotate on every successful refresh.
  • Each connection is bound to its OAuth client, user, team, scope, and MCP resource.
  • OAuth clients use Authorization Code with PKCE and do not need a client secret.

​
Supported standards

  • OAuth 2.0 Authorization Code with PKCE (S256)
  • RFC 8414 Authorization Server Metadata
  • RFC 9728 Protected Resource Metadata
  • Client ID Metadata Documents (CIMD)
  • RFC 7591 Dynamic Client Registration (DCR)
  • RFC 8707 Resource Indicators
New account connections must use this exact resource on authorization and token requests:
The authorization-server metadata is available at: