Endpoints

An endpoint is a named routing scope: a stable name your applications call, bound to a policy, a model set, and limits. Instead of scattering model names and provider choices across services, you hand each use case one URL-shaped answer and manage the rest from the console.

Why endpoints exist#

Application code should say what it needs — "draft a support reply" — not which provider serves it this quarter. Endpoints make that separation real:

• One name per use case — support-draft, code-review, embeddings-fast.
• Policy attached — each endpoint resolves through the policy engine, so budgets, timeouts, and fallbacks travel with the name.
• Copy-paste clients — the dashboard renders a ready example per endpoint in curl, Python, and JavaScript.
• Independent evolution — repoint the endpoint's models or strategy and every caller follows, with no deployment.

Using an endpoint#

Endpoints ride the same OpenAI-compatible surface. From the dashboard's Endpoints page, copy the example for your stack:

from openai import OpenAI

# Same SDK, same shape — the endpoint name selects the scope.
client = OpenAI(base_url="http://127.0.0.1:8080/v1", api_key="syn_live_...")

answer = client.chat.completions.create(
    model="support-draft",   # an alias bound to this endpoint's policy
    messages=[{"role": "user", "content": "Where is my refund?"}],
    max_tokens=256,
)

curl -s $GATEWAY/v1/chat/completions \
  -H "Authorization: Bearer $SYNAPASS_KEY" \
  -H 'Content-Type: application/json' \
  -H 'X-Synapass-Endpoint: support-draft' \
  -d '{"model":"support-draft","messages":[{"role":"user","content":"Where is my refund?"}]}'

The routing-intent headers (X-Synapass-*) are documented in Routing and the API reference.

Endpoints vs models vs policies#

A new use case means a new endpoint, a policy (or reuse), and an alias — ten minutes in the dashboard, zero code changes elsewhere.

Related#

• Policies · Routing · Models · Playground