Versioning

Know which changes can reach your integration without warning and which can't, so you write a client that keeps working as the API grows.

Available at launch

The version is in the path#

Every endpoint starts with /v1: https://api.unplugdining.com/v1/members. You move to a new version by changing the path.

What can change within v1#

Within v1 we only make additive changes. They ship without notice beyond the changelog, so your client must accept them:

Change	What your client must do
New fields on responses and webhook payloads	Ignore fields you don't know. Don't fail on them, and don't use strict schema validation that rejects them.
New optional request fields	Nothing. Leaving them out keeps today's behavior.
New endpoints	Nothing.
New webhook event types	Ignore types you don't handle and still return `2xx`. If you subscribe to `"*"`, you will receive them.
New values in fields marked "May grow"	Have a default branch. See below.
New error codes and reason codes	Fall back on the HTTP status for errors, and on `message` for reason codes.

Fields that may grow#

Reference pages mark enum fields that can get new values with "May grow". For example, activity type will gain expire when points expiry ships, and wallet source already lists challenge ahead of challenges. When you meet a value you don't know:

Show something neutral. An activity entry with an unknown type still has description and signed points; show those.
Don't crash, and don't drop the item from a list.
Don't map enums to exhaustive switch statements or strict enum types that throw on unknown values. In Swift and Kotlin, decode them into a type with an "unknown" case.

Fields not marked "May grow", such as status on a redemption, keep the values listed for all of v1.

What counts as breaking#

These only ship in a new version:

Removing or renaming a field, endpoint or enum value.
Changing a field's type or meaning, such as cents to dollars.
Making an optional request field required, or adding a required one.
Changing an error's status code or code for the same situation.
Adding values to an enum field not marked "May grow".

New versions#

Breaking changes ship as /v2. When it ships, /v1 keeps working, unchanged, for at least 12 months. The changelog announces the new version, lists every difference, and gives the date /v1 stops working.

Webhook payloads#

Every webhook envelope carries "api_version": "v1". The data.object inside has the same shape as the v1 API response for that resource, with the same additive rules: new fields and new event types can appear at any time.

Webhook

1
2
3
4
5
6
7
8
9{
  "id": "7f3a9c2e-4b8d-4e16-a0c5-1d6b8e2f9a47",
  "type": "points.changed",
  "created_at": "2026-11-05T14:08:52Z",
  "api_version": "v1",
  "livemode": true,
  "brand_id": "e5a1c7d9-2f4b-4c8e-a3d6-8b0f1e9c2a57",
  "data": { "object": { ... }, "previous_attributes": {} }
}

Check api_version before you parse data. When a new version ships, the changelog explains how to move your webhook endpoints to it.

The changelog#

The changelog lists every change with its date: additions, fixes, and each Coming soon item when it goes live. Check it when you plan work on your integration.