Document API key spend limits and key names on the billing page

[claude]

Requested by Gaurav Chadha · Slack thread

Before: A reader of the billing page found nothing about per-API-key spend limits. The only public mention sat in a single Enterprise bullet: "Set spending caps per API key or per team". The billing page named a "per-API-key spend limit" once, inside a crawl pre-flight note, with no section to explain it. Nothing told the reader that key names are editable, or that a limit counts credits instead of dollars.

After: The billing page has an "API key spend limits" section. It says that the key owner or a team admin can rename any key, including the key named Default, and can cap the credits one key uses per day, per week or per month. It names the dashboard page and the exact menu items. It states that a limit counts credits, not money, and that a limit of 1 means one credit.

How: one new section in billing.mdx, placed after the pay-as-you-go sections and before "Upgrading and Downgrading". No existing heading, anchor or copy changed, so no fragment links break. No locale file touched. The facts and the UI labels come from the app code in firecrawl-web.

Staying in draft: there is an open question about whether per-key limits are enforced, and the section promises a cap until that is settled.

🤖 Generated with Claude Code

https://claude.ai/code/session_017gT8R64Yuvq8jQszkLdtQo

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
firecrawl	🟢 Ready	View Preview	Sep 15, 2026, 1:30 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[firecrawl-spring]

The red check is a base failure, not this change

The job Locale literals and extraction-hostile markdown fails on the first step, sh scripts/check-locale-api-literals.sh. That step exits 1.

Correction to the first version of this comment. It said the other two steps pass and print their pass lines in the same log. That was wrong. The three scripts are three separate steps in one job, so a failing step ends the job and the later steps are skipped. The log holds no result for the locale literal selftest or for the extraction-hostile markdown check. CI cannot report on those two while step 1 fails. Both were run locally on the same tree instead, and both pass, with exit code 0 each.

The step reports 14 lines. Every line names a file under es/, fr/ or pt-BR/. Sample lines from the job log:

translated API literal: es/features/change-tracking.mdx uses `seguimientoDeCambios`, which no English page uses
translated API literal: es/webhooks/events.mdx uses `rastreo.iniciado`, which no English page uses
translated API literal: fr/sdks/cli.mdx uses `suiviDesModifications`, which no English page uses
translated API literal: pt-BR/v0/sdks/node.mdx uses `dadosRaspados`, which no English page uses
Localized pages must keep API identifiers in English, in code and in prose.

This pull request changes one file, billing.mdx, the base English page. It touches no locale tree. None of the 14 reported files is in its diff.

Evidence

1. A clean worktree at origin/main (37e7a17) fails the same step with exit 1 and the same 14 lines. Run locally there, the selftest and the markdown check both pass.
2. Two other open pull requests on the same base 37e7a17 are red on the same check:
   • Update agent source-of-truth docs to latest SDK versions #1415, head c65f8e77, run 34848328068, conclusion failure.
   • docs: document keyless feedback in the v2 API reference #1414, head fa8b8883, run 34801147840, conclusion failure.
3. The workflow runs on pull_request only. It has no push trigger, so main is never gated by it. Commit 37e7a17 carries no check run of this name, and 9f9e20a carries only Mintlify and Locadex. A red locale state can therefore land on main.

How main got here

#1393 added this check and restored the English identifiers. The locadex sync in #1394 rewrote the same pages from translation memory and merged red. #1406 reverted those hunks and made the check pass again. The later locadex syncs in #1411 and #1413 reintroduced the same strings. #1413 is the current main HEAD, 37e7a17.

What fixes it

Not this pull request. The fix belongs on main: revert the locale hunks again, and pin changeTracking, crawl.started and scrapedData as do-not-translate in the General Translation dashboard. The commit message on 9f9e20a already flagged that the translation memory would reintroduce them.

---

Generated by Claude Code