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

# SEC API status

> Check service availability, then collect the evidence needed to diagnose a specific API or MCP request

Use the public status page and a health request to assess whether the service is reachable. They do not establish that a particular issuer, filing, route, derived dataset, or upstream SEC source can satisfy your request. For that, retain the route response and its source fields.

```bash theme={null}
curl -sS "https://api.secapi.ai/healthz"
```

## Service surfaces

| Surface    | Address                                      |
| ---------- | -------------------------------------------- |
| Status     | [status.secapi.ai](https://status.secapi.ai) |
| API        | `https://api.secapi.ai`                      |
| Hosted MCP | `https://api.secapi.ai/mcp`                  |
| Health     | `https://api.secapi.ai/healthz`              |
| Readiness  | `https://api.secapi.ai/readyz`               |

`/healthz` reports service health; `/readyz` reports readiness. Preserve the response from the surface you checked. Provenance, freshness, warnings, and degradation fields from the route response remain the evidence for a data result.

## Diagnose one failed or surprising request

1. Review [status.secapi.ai](https://status.secapi.ai), then make one health request.
2. Reproduce the API or MCP request once with the same endpoint and redacted inputs.
3. Record the UTC timestamp, HTTP status, error `code`, `Request-Id`, and `traceparent` when supplied.
4. Honor `Retry-After` for rate limits. Do not loop on a quota, billing-cap, authorization, or validation response.
5. For a data issue, retain the returned source identifiers and state fields. Do not include an API key or private payload in a support report.

If health is successful but the route still fails, work from that route's error and request ID rather than assuming a general service outage. If the response succeeds but is partial, preserve the stated limitation instead of filling the gap from a different issuer, period, or surface.

Use [Request diagnostics](/request-diagnostics) to assemble the support record, [Troubleshooting](/troubleshooting) for recovery decisions, and [Freshness and source evidence](/freshness-and-trust) to distinguish service reachability from evidence-ready data.