Versioning and changelog

How versioning works#

The version is part of every path: /api/brand/v1. Within a version, these changes can arrive at any time, so write your integration to tolerate them:

• New endpoints.
• New attributes on a response object.
• New optional query parameters.
• New values in an enum, such as a new order status.

Removing or renaming an attribute, changing its type, or making an optional parameter required is a breaking change. It would ship in a new version, alongside the old one, never into v1.

Changelog#

v1, October 2026#

The first version of the Brand API: authenticated, read-only, one brand per key, with 14 endpoints across analytics, orders, opportunities, content, roster, recommendations, gifts, discount codes and surveys.

Retired endpoints#

v1 replaced the keyless public recommendations feeds. They answer 410 Gone, with no CORS headers.

To move over:

1. Create a key with the recommendations:read scope.
2. Move the call from the browser to your server, since keys never go in a browser.
3. Read data as the array: each item is one host, with host, product_count and products. Pagination moved from data.pagination to the top-level pagination, the host photo is now host.profile_photo, and brand and totals are gone (GET /me returns the brand).
4. Render the result into your page, or cache it and serve it from your own endpoint. See Recommendations.