# Kibble installation contract: section 4 of 29 (guide version 3)

> This is **one section only**, not the whole contract. Complete document: https://www.usekibble.dev/AI/guide.md

## 4. Versions and compatibility {#versions}

| Interface | Version | Where it shows |
| --- | --- | --- |
| This contract | guide version 3 | The first lines of the complete document. Bumped only when what an agent must do changes. Record it in the installation report. |
| Browser SDK | path `/sdk/v1/` | `<collector origin>/sdk/v1/kibble.js`. Each build is identified by the `X-Kibble-SDK-Version` response header (a content hash) and is also served immutably at `/sdk/v1/kibble-<hash>.js`. |
| SDK features | `kibble_sdk_features: 1` | `<collector origin>/sdk/v1/features.json` lists the commands, script options, markup, dataLayer events and features of the deployed build, with its `sdk_build` hash. |
| Collection envelope | `"v": 1` | Sent by the SDK; never hand-craft collection requests. The one exception is the packaged Shopify custom pixel, which cannot run the SDK ([Shopify](https://www.usekibble.dev/AI#shopify)). |
| Site manifest | `"kibble_catalog": 1` | The first field of every manifest. See [Site catalog](https://www.usekibble.dev/AI#site-catalog). |
| Staff and report API | `/api/v1` | Used by Kibble’s own app and assistants; an installation never calls it. |

There is no SDK release number and no runtime `kibble.version`. Do not invent one, and do not use dates as versions.

### Check what the deployed SDK supports

1. Fetch `<collector origin>/sdk/v1/features.json` (public, no credentials). Use the origin the person gave you, never a guessed one and never localhost for a production site.
2. Use only commands, options, markup and dataLayer events listed there. If something in this contract is missing from the file, the deployed SDK predates it: do not use it, and say so in the report.
3. If the file returns 404, the deployed SDK predates the features file. Use only the baseline below and note "SDK features file not available" in the report.
4. Record the `sdk_build` value (or the `X-Kibble-SDK-Version` header of `kibble.js`) in the installation report.

Baseline when no features file is available: the commands `consent`, `track`, `search`, `outcome`, `formAccepted`, `forget` and `flush`; the attributes `data-key`, `data-endpoint`, `data-consent`, `data-cookie-domain`, `data-connected-hosts` and `data-datalayer`; and the markup in [Semantic markup](https://www.usekibble.dev/AI#markup) and [Forms](https://www.usekibble.dev/AI#forms). Booking criteria markup (`data-kibble-criteria`) and Validation (Site Check) need a build that lists `markup.booking-criteria` and `site-check`. External connections (`data-tenant`, `data-routes`, `data-storage`, host and pattern entries in `data-connected-hosts`, per-destination handoff and the `decorate` command) need a build that lists the features `config.property-scope`, `cross-domain.destination-links` and `cross-domain.decorate`; on an older build do not install a connection recipe and say so in the report. The key-only installation (the standard GTM tag, settings fetched from Kibble) needs a build that lists `config.settings-by-key`; the consent platforms `consent.trustarc`, `consent.onetrust` and `consent.cookieyes`; event decisions `datalayer.event-mappings` and learned names `datalayer.learn-names`. The features file also lists `settings_consent_sources` and `event_mapping_kinds`. On an older build use a snippet with page settings (`data-consent` set) and say so in the report.

### Environments

- Copy examples here use the placeholders `pk_YOUR_PROPERTY_KEY` and `https://use.example-kibble-host`. Replace them with the values a person gives you for the environment you are installing in.
- Never ship a localhost, 127.0.0.1 or development collector origin, or a development property key, in a production build. Keep the values in the site’s existing environment configuration if it has one.

END OF SECTION versions