API versioning
How SafetyKit API versions work, the current and superseded versions, and how to upgrade.
API versioning applies to the Content API (POST /v1/content). Other endpoints are not versioned yet and ignore the version header. Versions are named by release date. A new version is released only for a backwards-incompatible change. Additive changes, such as new optional fields, ship under the existing version.
Each Content API request resolves its version in this order:
- The
SafetyKit-Versionrequest header, for exampleSafetyKit-Version: 2026-08-05. An unknown value returns a 400 with the list of valid versions. - Your account’s pinned version. Accounts are pinned to the version that was current when they integrated. Contact support@safetykit.com to change your pin.
- The latest version.
Every Content API response includes a SafetyKit-Version header naming the version that served it.
To test an upgrade, send the SafetyKit-Version header with the new version on individual requests before changing your account pin.
Versions
Section titled “Versions”| Version | Status | Notes |
|---|---|---|
2026-08-11 |
Current | Content API: request takes a content array of typed parts; response returns labels with a type discriminator |
2026-08-05 |
Superseded | Original content API shape |
2026-08-11
Section titled “2026-08-11”Breaking changes to POST /v1/content:
- Request: the
textandimagesfields are replaced by acontentarray of typed parts. Each part carries an optionalkeynaming where it came from. - Response: the
policiesandreference_set_matchesarrays are replaced by a singlelabelsarray. Each entry has atype:classifierentries carrylabeland a nullablescore;similarityentries carryset_idand appear only when a reference set matched. The per-policyversionfield is removed and the response includes the APIversionthat served it.
See the Content reference for the current shapes.
2026-08-05 (superseded)
Section titled “2026-08-05 (superseded)”POST /v1/content with the SafetyKit-Version: 2026-08-05 header or a pinned account.
Request:
{ "user_id": "user_123", "content_id": "post_42", "text": "Hey, is this still available?", "images": ["data:image/jpeg;base64,/9j/4AAQSkZJRg..."], "metadata": { "channel": "marketplace_dm" }}text and images are each optional. At least one is required. Text at most 16,000 characters, at most 20 images, 5MB per image, 6MB per request.
Response:
{ "content_id": "post_42", "user_id": "user_123", "policies": [ { "policy_id": "phishing", "version": "v3", "score": 0.12, "decision": "not_match", "escalation": "none" } ], "reference_set_matches": [{ "set_id": "known_scam_messages", "similarity": 0.94 }]}decision is match, not_match, or review. escalation is none, completed, or error. score is null when no classifier scored the policy. Full reference: Classify content (2026-08-05).
Backwards-compatible changes
Section titled “Backwards-compatible changes”The following never create a new version:
- Adding new API endpoints
- Adding new optional request fields
- Adding new fields to responses
- Adding new values to enums
- Adding new label or policy identifiers
- Changing the length or format of opaque identifiers and error messages