Skip to main content
Use this guide to decide whether one sec-api.io read path can move to SEC API. Test the route your application depends on, rather than relying on a feature table or a single response.

​
Pick the first production job

The public API reference is authoritative for supported parameters and response fields. Treat a successful response for one issuer or form as evidence for that scope only.

​
Compare identity before output

For each candidate filing, compare the CIK, form, filing date, accession number, and filing URL before comparing downstream text or financial values. Record requestId and any returned provenance, freshness, or warning fields.

​
Test the exact retrieval boundary

This route answers a bounded section-retrieval question. It is not a promise that every exhibit, arbitrary filing URL, or rendered representation is available. Keep the existing integration as a reversible fallback until your required filing families pass the same test.

​
Implement one reversible cutover

  1. Send credentials in x-api-key, not a query parameter or browser bundle.
  2. Dual-run a low-risk read path for a defined issuer and form set.
  3. Compare identities, pagination, nulls, units, and source records, not just headline values.
  4. Honor Retry-After for 429; do not retry authentication, authorization, billing, or hard-cap responses until their condition changes.
  5. Release behind a reversible control and retain request diagnostics for both paths.

​
Next action

Pick the lowest-risk production read, dual-run it for a defined issuer and form set, and record the acceptance result before moving another route.

Migration guide

Use the full cutover checklist.

API conventions

Review authentication, versions, pagination, and retries.

Error catalog

Turn a failed dual run into an actionable diagnosis.