> ## Documentation Index
> Fetch the complete documentation index at: https://docs.secapi.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Migrate from sec-api.io to SEC API

> Dual-run one sec-api.io workflow against SEC API and cut over only when identity, response behavior, and evidence meet your acceptance test.

Use this guide to move one production read from sec-api.io to SEC API. SEC API provides issuer resolution, filing retrieval, sections, and reported facts through its documented REST API. Do not assume similarly named endpoints have identical contracts.

## Pick one user job

Start with a low-risk workflow that has a clear pass or fail result.

| Current job            | SEC API path to evaluate                        | Evidence to compare                                                     |
| ---------------------- | ----------------------------------------------- | ----------------------------------------------------------------------- |
| Resolve an issuer      | `GET /v1/entities/resolve`                      | Company identity, ticker, CIK, and stored identifier.                   |
| Search filings         | `GET /v1/filings`                               | Form, filing date, accession number, filing URL, nulls, and pagination. |
| Read the latest filing | `GET /v1/filings/latest`                        | Resolved filing identity and retrieval time.                            |
| Read a section         | `GET /v1/filings/latest/sections/{section_key}` | Filing identity, section key, text availability, and returned warnings. |
| Read a reported fact   | `GET /v1/facts`                                 | Tag, unit, fiscal period, and filing context.                           |

The public API reference defines supported parameters and fields. A successful response for one issuer or form is evidence for that bounded case, not a coverage claim.

## Verify identity before downstream output

```bash theme={null}
curl --fail-with-body -sS -H "x-api-key: $SECAPI_API_KEY" \
  "https://api.secapi.ai/v1/entities/resolve?ticker=AAPL"

curl --fail-with-body -sS -H "x-api-key: $SECAPI_API_KEY" \
  "https://api.secapi.ai/v1/filings?ticker=AAPL&form=10-K&limit=10"
```

For each matched filing, compare ticker, CIK, form, filing date, accession number, and source URL before comparing extracted text or values. Store the request parameters, retrieval time, `requestId`, and available provenance, freshness, materialization, or warning fields.

## Dual-run the exact retrieval you need

```bash theme={null}
curl --fail-with-body -sS -H "x-api-key: $SECAPI_API_KEY" \
  "https://api.secapi.ai/v1/filings/latest/sections/item_1a?ticker=AAPL&form=10-K&mode=full"
```

Test your actual filing families, exhibits, historical window, and rendering needs. SEC API may be a good fit for a documented filing-and-section workflow. Keep your existing provider or direct EDGAR path where it better serves an unqualified requirement.

## Cut over one reversible read

1. Use `x-api-key` for machine credentials and keep it out of URLs and browser bundles.
2. Dual-run a defined issuer and form set.
3. Compare source identity, pagination, nullability, and units as well as business fields.
4. Honor `Retry-After` for `429`; do not retry a failure until its condition changes.
5. Release one path behind a reversible control and retain a secret-free request record.

## Next step

Promote only the read that passes your recorded acceptance test. Then repeat the process for the next workflow rather than treating a single cutover as platform-wide parity.

<CardGroup cols={3}>
  <Card title="Filing API reference" icon="book-open" href="/api-reference/filings">Review routes and response fields.</Card>
  <Card title="API conventions" icon="braces" href="/api-conventions">Apply authentication, pagination, and retry rules.</Card>
  <Card title="Error catalog" icon="circle-alert" href="/error-code-catalog">Interpret a failed dual run.</Card>
</CardGroup>