API versioning
The rules we follow so an integration you build today keeps working — including the form action URLs embedded in your sites.
The /v1 prefix is permanent
Every endpoint lives under a version prefix — /v1/submit/…, /v1/api/… — and /v1 never goes away while it has users. This matters most for the submit endpoint: the action URL pasted into your HTML forms keeps working without edits.
What can change inside /v1
Additive, backwards-compatible changes ship without a version bump. Expect us to:
- add new endpoints;
- add new optional request fields and parameters;
- add new fields to JSON responses;
- add new values to the error-code catalog.
Write clients accordingly: ignore response fields you don't recognize, and treat unknown error codes as generic failures of their HTTP status class.
What never changes inside /v1
- Existing fields are not removed or renamed, and their types don't change.
- Existing endpoints are not removed, and their semantics don't change.
- Existing error codes keep their meaning and status — they are part of the contract (see Error codes).
- Authentication schemes (session cookies,
fc_live_Bearer keys) are not dropped.
Breaking changes ship as /v2
If we ever need a breaking change, it ships under a new prefix, and /v1 keeps working for at least 12 months after /v2 is generally available. Deprecations are announced by email to affected account owners and documented here well before any cutoff.
API keys and rate limits
Management-API keys are not tied to an API version — the same fc_live_ key works across versions. Rate limits (currently 120 requests/minute per key) may be tuned over time; we treat raising limits as non-breaking and will announce any reduction in advance.
Next steps
- Submit API reference — the endpoint your forms post to.
- Management API — key-authenticated programmatic access.
- Error codes — the canonical catalog.