Unique API Rollout

1 min read

What changes during the rollout?

  • The new API runs as a separate service: unique-api.

  • The client-facing base path remains /public/chat, so customer integrations do not need to change their URLs.

  • The gateway routes public api requests to unique-api.

  • The legacy API remains available through node-chat; in QA and UAT1, a dedicated bypass route is retained for API parity testing. This is optional for other tenants.

  • Therefore, each customer rollout requires a gateway configuration change.

One point requiring coordination is RBAC and CMT hairpinning. For Public API key traffic, roles are resolved by querying Zitadel. We should review CMTs that call the public gateway from inside their own environment. Gatekeeper may reduce the authorization impact, this needs to be checked.

Plan

For each rollout batch, I propose that we:

  1. Confirm the customer’s gateway and hairpinning setup.

  2. Deploy and verify unique-api health.

  3. Monitor errors and authorization denials before proceeding with the next batch.

  4. Keep a documented rollback path to the legacy node-chat route.

Last updated