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

# API Stability & Versioning

> How the Context.dev API is versioned, what counts as a breaking change, how deprecations are announced, and what stays stable when extraction models improve.

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:

```text theme={null}
https://api.context.dev/v1
```

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](/api-reference/web-scraping/markdown) 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](/api-error).

## Deprecation policy

When something must be retired:

1. It is announced in the [changelog](/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](/api-reference/web-extraction/extract), [Product](/api-reference/web-extraction/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 [support@context.dev](mailto:support@context.dev) to discuss options on Enterprise plans.

## SDK versioning

The official SDKs (TypeScript, Python, Ruby, Go, PHP) follow [semantic versioning](https://semver.org) and are generated from the same [OpenAPI specification](https://app.stainless.com/api/spec/documented/context.dev/openapi.documented.yml) 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](/changelog) — every API, SDK, and pricing change, dated.
* [Status page](https://status.context.dev) — live uptime and incident history.
* Email — deprecations and security notices go to affected organizations directly.

<Info>
  Questions about a specific guarantee, or need a longer deprecation window? Email [support@context.dev](mailto:support@context.dev).
</Info>