Unique API Version 2026.03.01

Summary

We are rolling out a new Unique API (formerly Public API) version — a significant improvement focused on security, reliability, and developer experience.

The base URL does not change. Your integration will continue to work at https://gateway.unique.app/public/chat/{resource} (and https://gateway.unique.app/unique-api/{resource} for the new standalone service).

This rollout does not require any client action. The new implementation is enabled progressively — one API domain at a time, through internal environments first and then client environments — until it fully replaces the old version. Your integration, base URL, API key, and auth all remain unchanged throughout.

The one exception: if you want early access to endpoints that only exist in the new Unique API, you can opt in ahead of your normal rollout wave by setting the x-api-version request header to the new version.

Rollout Stages

The new version is enabled step by step, in this following order. Each step is validated before moving to the next, so issues are caught early and affect the smallest possible group.

Order by domain

Domains go live in the order below, lowest-risk first, one domain per even release. Each domain clears QA and UAT before it reaches client environments, and any single domain can be reverted on its own without affecting the others.

Dates are targets and may shift if a domain needs longer to validate. Domain membership is fixed — a domain always moves as one unit, so a workflow is never split across two versions mid-flight. Once every domain has rolled out in every environment, the previous implementation is retired.

What has Changed

The new version offers the same features you're used to and has been thoroughly tested to ensure a smooth transition. That said, a few behavior changes could cause previously-succeeding calls to fail once the new version reaches your environment. Because the rollout is per domain, these may appear for some resources before others.

1. Role-based access control (RBAC) is now enforced — calls made by users without the required permissions will now be rejected with a 403 Forbidden.
   If you see this: it indicates your user is missing a required role or permission. Contact your account team if you believe you should have access.

2. Stricter request validation — requests that don't conform to the new validation rules will now fail with a 400 Bad Request.
   If you see this: check the Swagger docs for the correct schema — a field or value in your payload likely doesn't match the new contract. Check the error message for more details.

3. Improved error handling — internal errors now return a 422 with a clear, accurate error message instead of a generic failure, making issues easier to identify and fix.

Request size limits, the proxy route allow-lists, and every other documented contract are unchanged between versions.

Endpoints only in the new version

These are the endpoints that do not exist in the previous version — the reason to opt in early with the x-api-version header rather than waiting for your rollout wave. Everything else is available in both versions, so there is no functional reason to opt in unless you need one of these.

Because these have no equivalent in the previous version, they are always served by the new implementation regardless of your rollout wave.

Questions & Support

If you have questions or run into issues once the new version reaches your environment, reach out to:

• Your customer success manager

• Or open a support ticket referencing "Unique API Rollout"

When reporting an issue, including the resource path and whether you send the x-api-version header helps us identify which version served your call.