Skip to main content
mnemom-api uses date-based header versioning alongside the /v1/ URL prefix. This gives you fine-grained control over which API behavior your integration uses, independent of when you deploy.

​
How it works

Send the X-Mnemom-Version header with every request:
Every response echoes the version used:
If you don’t send the header, the latest behavior is used. For production systems — including AI agents — always pin to a specific date.

​
Current version

The current stable version is 2026-08-17. This is the version to pin to for new integrations.

​
SDK defaults

The TypeScript SDK (@mnemom/sdk) does not currently expose a version-pinning option — every request goes through with no X-Mnemom-Version header, so it always gets the latest behavior:
If your integration needs to pin to a specific date, set the header yourself on raw HTTP calls to the API rather than relying on an SDK option.

​
Support window

The 18-month standard window is longer than most APIs. This reflects mnemom’s service to the agentic internet: AI agents that call our API may be embedded in contexts that cannot self-update in response to deprecation notices.

​
Deprecation signals

When a version you are using is deprecated, responses carry (RFC 8594):
No version is currently deprecated — every supported version date is fully live. When a version does enter its sunset window, these headers appear on every response made with that version pinned.

​
Breaking vs. non-breaking changes

Breaking changes always get a new version date:
  • Removing or renaming response fields
  • Changing field types
  • Removing endpoints
  • Making optional parameters required
  • Changing default behavior
Non-breaking changes (no new version date needed):
  • New endpoints
  • New optional fields in responses
  • New optional request parameters
Additive changes are still risky for AI agents. An AI agent with a hardcoded response schema may fail if unexpected fields appear. Use lenient JSON parsing — always ignore unknown fields — and your integration will be safe across non-breaking changes.

​
URL versioning (/v1/ vs /v2/)

The /v1/ URL prefix represents the current API generation. A /v2/ would only be introduced for a complete API redesign — not for individual breaking changes. URL version increments are expected to happen at most once every several years. Date header versioning handles all evolution within /v1/.

​
Version history