Versioning & support policy

DRAFT — this policy takes effect when this banner is removed. The commitments below describe how we intend to operate; until then they are informational, not contractual.

You are building on our API. This page is the promise about what we will and will not break, how much warning you get, and how to reach a human.

API versioning

The version lives in the path: /api/v1/partner/…. Everything documented under v1 keeps its contract for the life of v1.
Additive changes are not breaking and can ship any time: new endpoints, new OPTIONAL request fields, new response fields, new enum values on fields documented as open, new webhook event types. Write your client to ignore fields it does not recognize.
Breaking changes only ship as a new version prefix (v2). Removing or renaming a field, changing a type, tightening validation on existing input, or changing an error code's meaning will never happen silently inside v1.
Parallel run: when a new major version ships, the old version keeps working for at least 6 months from the announcement.
Deprecation notice: at least 90 days before anything documented is retired, announced in the Developer Console and by email to every key holder that called the affected surface in the prior 90 days.
Security exception: if a change is required to close an active vulnerability, we may act faster — with a console notice and email explaining what changed and why.

Key & credential lifecycle (already in effect)

Surface	Commitment
Login-assertion signing keys (JWKS)	New keys are published in the JWKS at least 7 days before signing moves to them; retired keys stay in the JWKS at least 30 days after. Cache the JWKS up to 1 hour and always select by `kid`. If you cannot refresh during an emergency rotation, `POST /login/verify` is always consistent with the live set.
Login assertions	ES256, header `typ: "blasts-login+jwt"`, fixed 300-second lifetime, single mint per ceremony, pairwise `sub`. These are contract, not defaults.
API key rotation (self-serve)	Rotating in the console keeps the old key + secret working for a 24-hour grace window while you swap.
Push credentials (BlastsKit)	APNs keys and FCM service accounts you upload are write-only: stored for dispatch, returned only as fingerprints, replaced or deleted by you at any time.

Sandbox promise

Sandbox keys (pk_test_…) are free forever: 0 credits per send, [SANDBOX] body prefix, 100 sends per UTC day, ceremonies fenced to the console account that minted the keys. Sandbox is a permanent tier, not a trial.

Support

Channel: AL@SavingsSites.com — include your partner_id (never your signing secret; we will never ask for it).
First response: we aim to respond within 3 business days; production-down reports are worked first.
Live-key review (console request queue) is reviewed promptly.
Docs are the contract: where this site's OpenAPI spec and behavior disagree, tell us — the fix goes to whichever side is wrong, with the changelog noting it.

SDK versioning (BlastsKit)

Published SDK packages (@blasts/kit-*, mobile kits) follow semver: breaking changes only in majors, deprecations marked at least one minor ahead. Each SDK major pins the API version it speaks, so an API v2 never breaks a pinned SDK during the parallel-run window. Until a package ships, the sample app pattern against the raw HTTP surface is the supported path.

Owner: TIPS Marketing Services Corp · AL@SavingsSites.com