> ## 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.

# Build a first SEC API integration

> Choose REST, an SDK, the CLI, or MCP and produce a source-cited filing artifact

SEC API provides the same underlying data contract through direct REST, language SDKs, a CLI, and hosted MCP. Choose the interface for your execution environment, but keep the same discipline in each: authenticate server-side, retrieve a source record, and retain its identifiers with every conclusion.

## Authentication

Create an API key in the signed-in [dashboard](https://secapi.ai/app) and provide it to the calling process as `SECAPI_API_KEY`.

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

Normal machine data requests use `x-api-key`. Do not expose a machine key in frontend code or use it as an `Authorization: Bearer` token. Browser-session bearer authorization is for documented signed-in account operations.

## Choose an interface

| Interface | Contract and ownership                                                                                                   | Best fit                                            |
| --------- | ------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------- |
| REST      | Your application owns HTTP, serialization, timeouts, retries, and deployment.                                            | Any runtime or a service that needs direct control. |
| SDK       | A language client wraps public REST endpoints. Your application still owns deployment policy and downstream persistence. | JavaScript, Python, Go, or Rust services.           |
| CLI       | A terminal client calls the same service using environment-backed credentials.                                           | Local investigation and shell scripts.              |
| MCP       | A compatible client invokes hosted tools through JSON-RPC and can discover schemas at runtime.                           | Interactive agent or research workflows.            |

The [First request flows](/first-request-flows) page gives a source-backed example for each path. Use the [API reference](/api-reference) as the authority for REST parameters, response fields, and endpoint-specific limits.

## Preserve provenance

For filing-derived work, persist `accessionNumber`, `form`, `filingDate`, `filingUrl`, and `requestId` when returned. That is the artifact a reviewer needs to find the source again. Also preserve returned `provenance`, `freshness`, `materialization`, pagination, warning, and trace fields when the route supplies them.

Do not treat a current latest filing as immutable. Record retrieval time and source identifiers, and distinguish the filing's disclosed facts from your application's or agent's interpretation.

## Errors, limits, and repeated work

Correct `400` requests from the reference or discovered MCP schema. Repair credentials for `401` and `403`; stop for `402` billing or entitlement conditions. On `429`, honor `Retry-After` when present and avoid parallel retry loops. Preserve the request identifier from both successes and failures.

Before a repeated workflow, read `GET /v1/billing` and `GET /v1/limits` with the same API key, then use `POST /v1/billing/quote` for the current billing decision. Quotes do not reserve usage. Read [Agent billing](/agent-billing) for account-boundary details and [API conventions](/api-conventions) for pagination and response behavior.