Skip to navigation
APIGetting Started

Versioning

Date-stamped API versions, pinned per request or per key.

The API surface is versioned with date stamps. Pin one per request with the optional SpreadSpace-Version header:

curl https://api.spreadspace.app/api/borrowers \
  -H "Authorization: Bearer ss_live_..." \
  -H "SpreadSpace-Version: 2026-10-07"

Resolution order

Each request resolves its version in this order:

  1. The SpreadSpace-Version header, if sent. An invalid value returns 400 invalid_version.
  2. The API key’s pinned version, if one is set.
  3. The latest supported version.

Supported versions

  • 2026-10-07 (latest)
  • 2026-07-19
  • 2026-05-03

What each version added is listed on the Changelog.

Stability

Changes that add a field, an enum value, an operation or an event ship under the current version stamp. The reference pages describe each object as it stands, and the Changelog lists new operations, events and SDK releases.

A breaking change ships under a new date stamp: a field or operation removed or renamed, a type or a status code changed, a required field added to a request. A caller pinned to 2026-10-07 or a later stamp keeps that stamp’s behaviour for at least twelve months after the next stamp is published, and the changelog entry that introduces a stamp names what changed.

The stamps 2026-07-19 and 2026-05-03 remain accepted and resolve to the current behaviour: a request that pins either one answers as 2026-10-07 does. What 2026-10-07 changed is listed on the Changelog.

Detecting drift

Every response echoes the resolved version in the SpreadSpace-Version response header, so a client can detect drift between what it sent and what the server resolved.

What a pinned caller is promised is stated under Stability.