Skip to main content
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.

​
Service surfaces

/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, 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 to assemble the support record, Troubleshooting for recovery decisions, and Freshness and source evidence to distinguish service reachability from evidence-ready data.