Self-hosted endpoint

Some organizations prefer that developer tools never call an external hostname directly. Instead they stand up an internal endpoint, within their own network, that fronts the Syntic model and forwards requests to api.syntic.ai on the tools’ behalf. Pointing Syntic Code at such an endpoint gives you a single, controlled boundary between your developers and the outside world without changing which model answers their prompts.

What a self-hosted endpoint is

A self-hosted endpoint is a service you run that speaks the same API as api.syntic.ai. Syntic Code sends its requests there; the endpoint applies whatever policy you require, then relays the request upstream and streams the response back. Because it holds the real upstream credential, individual machines never see it. This is closely related to an LLM gateway, and in practice the same service often plays both roles. The key idea is that the CLI’s view of the network ends at your endpoint.

Pointing Syntic Code at it

Set the base URL so syntic sends every request to your internal service, and issue credentials that your endpoint recognizes rather than the upstream key:

export SYNTIC_BASE_URL="https://syntic.internal.example.com"
export SYNTIC_API_KEY="issued-by-your-endpoint"

Distribute these through server-managed settings so they apply automatically and cannot be repointed. Your endpoint must implement the request paths, headers, and streaming response format Syntic Code expects, so replies still render incrementally.

Operating it responsibly

Treat the endpoint as production infrastructure: give it health checks, redundancy, and monitoring, because every session that depends on it stops if it goes down. Keep its added latency small since Amara streams tokens interactively. Secure the upstream credential in a secret manager, rotate it without touching client machines, and log requests at the endpoint if compliance requires an audit trail, taking care to handle any sensitive content in prompts according to your data policy.