How-to guideApplies to: Unified engine deployments
Use the HTTP address and API prefix of the instance you intend to operate. The native engine routes use /api/v1. An embedded deployment can mount Unified under another prefix, such as /api/v1/unified.
Select the connected instance
Use your engine’s HTTP origin and API prefix in your client. The OpenAPI document uses native paths. Account for any deployment-specific prefix when importing it into another client.
Understand the access context
The native HTTP API uses its configured owner for engine requests. The owner is not a field a caller can override in each body. A platform or gateway can apply its own login and access rules before requests reach Unified.
Do not assume that a bearer token is required or supported by every native deployment. Use the access mechanism configured by your host or gateway.
For a gateway that needs an Authorization header, add it to the copied code in your own client. Keep API credentials in your client configuration.
Browser restrictions
A different-origin engine must permit the browser’s request through its CORS policy. Your client must follow the deployment’s access controls. Browser-managed headers such as Cookie and Host cannot be set freely from JavaScript.
A network failure can mean an unreachable address, a browser policy, a missing login, or a lost response. Inspect network and server evidence before changing a mutation’s identity.
Use resource revisions
Read the current resource before updating it. Requests use fields such as expected_revision or catalog revision to reject stale changes. Request identity and revision checks have different purposes; see Request identity.Last modified on November 4, 2026
