API changelog

Every change to the REST API, dated and versioned. Breaking changes ship under a new major version with a new URL prefix; we don't mutate an existing endpoint's contract. Format: Keep a Changelog. Versioning: SemVer.

Current API version: v1.0.0 · OpenAPI 3.1 spec · Official SDKs

v1.0.0 — 2026-04-18

Initial public release. 46 endpoints across six resources. All subsequent 1.x releases are additive; no field is removed from a response within a major version, and no required field is added to a request body.

  • Authentication: bearer-token auth via Authorization: Bearer abnd_qrpro_<secret>. Keys created and rotated at /account/keys, stored SHA-256 hashed at rest.
  • Rate limits: plan-based, with X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset on every response. 429 includes Retry-After.
  • Codes: CRUD (GET/POST/PATCH/DELETE /api/codes, /api/codes/{id}), slug availability check, bulk import, tag / group filters.
  • Analytics: per-code scan analytics as JSON (/api/codes/{id}/analytics) or CSV (.csv variant), plus heatmaps, lifetime, and deep-stats endpoints. Privacy-safe: country + device class only, no IP, no UA, no city.
  • Groups: CRUD plus group-level stats and heatmaps.
  • Teams: CRUD, member management, invites, activity feed.
  • Webhooks: CRUD. Outbound deliveries signed with HMAC-SHA256 via X-Abundera-Signature: t=<unix_ts>,v1=<hex> (Stripe-compatible shape). Official SDKs ship a verifyWebhookSignature helper.
  • User: /api/user/me, scope stats, workspace stats, scan usage, weather overlay, data export.
  • Audit: /api/audit for read-only access to audit log entries on plans that include it.

How versioning works

The URL prefix is the major version. Today: /api/... (v1). A future breaking change would ship as /api/v2/..., and v1 would remain available for a deprecation window of at least 12 months, with Deprecation and Sunset response headers plus one-click account-wide notifications.

What counts as a breaking change:

  • Removing an endpoint.
  • Removing a field from a response, or changing its type or semantics.
  • Adding a required field to a request body.
  • Changing the meaning of an existing error code.

What does NOT count as breaking (ships within the current major without a new URL):

  • Adding a new endpoint.
  • Adding a new optional field to a request.
  • Adding a new field to a response.
  • Adding a new enum value to a field whose values were already documented as extensible.
  • Adding a new error code to an endpoint that already returned errors of the same category.

Official SDKs track the current major version. Each SDK's own version is independent of the API version (an SDK bugfix release doesn't move the API version and vice versa).

Subscribing to changes

  • RSS / Atom: planned. Email support@abundera.ai if you want it sooner.
  • Webhook: subscribe to api.version.released and api.version.deprecated via /api/webhooks to get notified programmatically.
  • Email: account owners are emailed for any deprecation that affects endpoints they've called in the last 90 days.