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

# Versioning & deprecation

> How the OEM Partner API evolves — the dated version header, what counts as additive vs breaking, and the 12-month deprecation window.

The OEM Partner API is versioned by a single dated string surfaced on every
response:

```http theme={null}
X-VisIQ-Partner-Api-Version: 2026-07-11
```

## Additive changes ship anytime

We add — without a version bump — new endpoints, new **optional** request
fields, new response fields, new enum values, and new webhook event types.
Integrations MUST be tolerant of these:

* Ignore unknown response fields rather than failing.
* Do not assume the response shape is exhaustive.
* Treat unknown webhook `X-VisIQ-Event-Type` values as no-ops.

## Breaking changes get a new version

A breaking change — removing or renaming a field, changing a type or a
default, tightening validation, or changing an endpoint's semantics — ships
under a **new dated version**. The previous version continues to function for a
**12-month deprecation window** from the announcement, after which it is
retired.

During a deprecation window:

* Both versions are served; the version header reflects the one in effect.
* Deprecated fields/endpoints are documented as such with the sunset date.
* We notify partner accounts ahead of retirement.

## Stability guarantees

* **Money** is always integer cents.
* Key formats are stable: provisioning keys are `vqp_…`; minted sub-tenant
  harness keys are `vq_prod_…`.
* `X-VisIQ-Event-Id` is a stable idempotency handle — always dedupe on it.
* The webhook signature scheme (`t=<ts>,v1=<hmac-sha256(t + "." + body)>`) is a
  versioned contract; any change ships as a new signature version, never a
  silent swap.