Firecrawl waitFor and wait actions: Sume's 10 s combined budget

Firecrawl's guide says the combined time across all wait actions and waitFor must not exceed 60 seconds. On Sume, wait_for_ms runs 0 to 10000 and the combined waits must be 10000 ms or less and less than timeout_ms. Rebudget any lazy-load wait to 10 seconds.

How do the two budgets compare?

Both tools count a page-level wait and wait actions together. Only the size differs.

What does a valid request look like?

Here a 3 s page wait plus a 2 s wait action uses 5000 ms of the 10000 budget.

curl -X POST https://api.sume.com/v1/firecrawl/scrape \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/gallery",
    "wait_for_ms": 3000,
    "actions": [
      { "type": "scroll", "direction": "down" },
      { "type": "wait", "milliseconds": 2000 }
    ]
  }'

Why not wait longer?

A sync scrape also ends at the client deadline, 35 s through MCP; see the deadline post.

What if the content still has not loaded?

Try fresh: true, which the description says bypasses cached content, or scroll in an action instead of waiting. If it still fails, treat the page as not scrapable in this call. The docs are in MCP tools and gates.