Skip to main content
Context.dev is built to run inside long-lived production pipelines. This page is the contract: how the API is versioned, what we will and won’t change under you, and how much notice you get when something is retired.

​
Versioning scheme

Every endpoint lives under a versioned base path:
The version in the path is the compatibility contract. As long as you call /v1, the request and response shapes documented in the API reference keep working. A change that can’t be made compatibly ships under a new base path (/v2) and runs alongside /v1 — existing integrations are never switched over silently.

​
What we can change without notice (non-breaking)

These are additive and safe by design. Your client should tolerate them:
  • New endpoints and new optional request parameters.
  • New fields in JSON responses. Parse what you need and ignore unknown keys — don’t fail on unrecognized fields.
  • New enum values in fields documented as open-ended (for example, new social platforms in a brand’s socials list).
  • Bug fixes that bring behavior in line with the documented contract.
  • Performance improvements, cache behavior, and infrastructure changes that don’t alter response shapes.

​
What we treat as breaking

We do not ship these inside /v1 without a deprecation window:
  • Removing or renaming an endpoint, request parameter, or response field.
  • Changing a field’s type or meaning.
  • Making an optional parameter required.
  • Tightening validation in a way that rejects previously valid requests.
  • Changing an error code or status code documented in the error reference.

​
Deprecation policy

When something must be retired:
  1. It is announced in the changelog with a dated entry, and organizations that called the affected surface in the previous 90 days are notified by email.
  2. The deprecated surface keeps working for at least 90 days after the announcement. Enterprise agreements can extend this window.

​
AI extraction and model changes

Schema-based extraction endpoints (Extract, Product, classification) are contracted on your schema, not our model:
  • Output always validates against the JSON Schema you supply. That contract holds across every model change.
  • Underlying models are upgraded to improve accuracy; the request and response envelope does not change when they are.
  • Classification endpoints return codes from fixed official code sets — NAICS (2022) and SIC (1987 / SEC EDGAR) — which change only when the issuing bodies revise them.
If you need extraction behavior held stable for a regulated pipeline, email [email protected] to discuss options on Enterprise plans.

​
SDK versioning

The official SDKs (TypeScript, Python, Ruby, Go, PHP) follow semantic versioning and are generated from the same OpenAPI specification that powers this reference, so they never drift from the live API. Breaking SDK changes only ship in major versions; pin a major version and minor/patch upgrades stay compatible.

​
Where changes are announced

  • Changelog — every API, SDK, and pricing change, dated.
  • Status page — live uptime and incident history.
  • Email — deprecations and security notices go to affected organizations directly.
Questions about a specific guarantee, or need a longer deprecation window? Email [email protected].