Firecrawl /support/ask is an AI support agent exposed as an API. Describe your issue and get back a verified diagnosis with actionable fix parameters — typically in 15–30 seconds.
Think of /support/ask as a senior Firecrawl engineer on-call for your agent.
The Ask API is designed primarily for AI agent callers. If you're building agents that use Firecrawl for scraping, crawling, or data extraction, wire /support/ask into your error-handling flow for autonomous issue resolution.
Two endpoints#
| Endpoint | Auth | Who it's for | What it does |
|---|---|---|---|
POST /support/ask | Your Firecrawl API key | Your agents and apps | Full diagnostic loop scoped to your team |
POST /support/docs-search | Your Firecrawl API key | Your agents and apps | Docs-grounded answers from Firecrawl's public documentation |
Quick start#
Debug a failing crawl#
Search the docs#
Debug a failed job#
Every Firecrawl job — scrape, crawl, batch scrape, search, map, or extract — can be debugged with /support/ask. Describe the failure in plain language and include the job ID when you have one; the agent pulls that job's logs and your account state before answering.
Include as much of this as you have — each piece narrows the diagnosis:
| Detail | Why it helps |
|---|---|
| Job ID | Lets the agent read that job's logs, status, and per-page results directly |
| Target URL | Surfaces site-specific blockers like bot protection, JS rendering, or robots rules |
| Error message or status code | Separates rate limits and credit exhaustion from scrape-level failures |
| What you expected | Distinguishes a hard failure from a job that "succeeded" with missing content |
rationale | Tells the agent what the end user is after so it prioritizes the right evidence |
What Ask checks for common failures#
| Symptom | What the agent investigates |
|---|---|
Job status failed | Job logs, upstream HTTP status, proxy and retry history |
| Crawl returned fewer pages than expected | limit, maxDiscoveryDepth, includePaths/excludePaths, sitemap coverage, robots rules |
| Empty or truncated markdown | Client-side rendering, waitFor timing, required actions, onlyMainContent trimming |
401 / 402 / 429 responses | API key validity and restrictions, remaining credits, plan rate limits |
| Job stuck or timing out | Queue state, page-level timeouts, job concurrency for your plan |
| Webhook never fired | Delivery attempts, endpoint responses, signature verification failures |
Don't have a job ID? Hover a row's URL in Activity Logs and click Copy ID, or use the id returned when you started the job.
Debug from Activity Logs#
If you'd rather not write the call yourself, the dashboard runs the same agent for you. Open Activity Logs and look for the sparkles button in the Actions column of a failed row — its tooltip reads Debug issue. It only shows up on jobs that failed or finished with errors on child requests, so successful and in-progress jobs won't have one.
Clicking it starts the diagnosis straight away; there's no prompt to write. Firecrawl sends that job's URL, endpoint, status, error message, and scrape parameters to the same agent behind /support/ask, which then reads the job's logs and your account state. Scraped page content is never included.
The panel that opens gives you:
| Element | What it is |
|---|---|
| Diagnosis | The agent's explanation of what went wrong and what to change |
| Confidence badge | High, medium, or low — how sure the agent is in the answer |
| Validated badge | Shown when the agent tested its own suggested fix and the test passed |
| Suggested fix | The corrected parameters as JSON, with a copy button — paste them into your next call |
| Sources | Links to the docs pages the answer draws on |
If the diagnosis doesn't resolve it, Open support ticket at the bottom of the panel files a ticket with the agent's analysis already attached, so you don't have to re-explain the failure.
Dashboard debugging is capped at 30 runs per hour per team, and your team needs at least one API key — the agent runs under your own key, so it only ever sees your jobs.
Once you have a diagnosis, apply the returned fixParameters and retry — see the agent retry pattern below.
How it works#
When you call /support/ask, the AI agent:
- Gathers evidence — inspects your job logs, account state, credit usage, and relevant documentation in parallel
- Diagnoses the issue — reasons across all evidence to identify the root cause
- Proposes a fix — generates machine-actionable
fixParametersyou can apply directly to your next API call - Validates the fix — when possible, tests the fix against the live Firecrawl API (e.g., retrying a scrape with adjusted parameters) and reports the result
Using Ask in your agent#
The key design pattern: call /support/ask when your Firecrawl API call fails or returns unexpected results, then use the fixParameters to retry.
Python example#
Node.js example#
Agent retry pattern#
Parameters#
/support/ask#
| Parameter | Type | Required | Description |
|---|---|---|---|
question | string | Yes | What to debug (1–8,000 characters) |
rationale | string | No | Recommended for AI callers. What the end user is trying to accomplish. Helps prioritize evidence gathering. |
context | object | No | Free-form metadata from your agent, included in the debugging prompt |
/support/docs-search#
| Parameter | Type | Required | Description |
|---|---|---|---|
question | string | Yes | The question to answer (1–8,000 characters) |
Response#
/support/ask response#
The actual answer, fixParameters, and validation.evidence are produced per request by the agent based on your specific run; the example above shows the response shape, not a real diagnosis.
/support/docs-search response#
Performance#
| Metric | Typical | Maximum |
|---|---|---|
| Latency | 15–30 seconds | 60 seconds (hard ceiling) |
API Reference#
Have feedback or need help? Email help@firecrawl.com.
Are you an AI agent that needs a Firecrawl API key? See firecrawl.dev/agent-onboarding/SKILL.md for automated onboarding instructions.

