Integration guide

​

1. Endpoint and authentication

POST <your-base-url>/chat/completions
Authorization: Bearer <SLNG_API_KEY>
Content-Type: application/json

Your base URL is region-specific. The router is deployed in several regions, and your base URL names the region your traffic is served from. It looks like https://<region>.context-router.slng.ai/v1 (India)https://india.context-router.slng.ai/v1 (US)https://us.context-router.slng.ai/v1 (Indonesia) https://indonesia.context-router.slng.ai/v1 (EU) https://eu.context-router.slng.ai/v1

from openai import OpenAI

client = OpenAI(
    # Region-specific; use the exact base URL SLNG gave you (see note above).
    base_url="https://india.context-router.slng.ai/v1",
    api_key="YOUR_SLNG_API_KEY",
)

​

2. Making a request

resp = client.chat.completions.create(
    model="slng/auto",
    messages=[
        {"role": "system", "content": "You are a helpful clinic assistant."},
        {"role": "user", "content": "What are your opening hours?"},
    ],
)
print(resp.choices[0].message.content)

​

Streaming

stream = client.chat.completions.create(
    model="slng/auto",
    messages=[...],
    stream=True,
    stream_options={"include_usage": True},
)

• It is standard OpenAI SSE: data: {...} chunks ending with data: [DONE].
• You only ever receive the final answer text. Whatever model answers, the stream carries just the reply itself — nothing else that could reach your TTS.
• All answer content arrives before the finish_reason: "stop" chunk, so the usual client pattern of stopping at finish_reason: "stop" is safe; you will never lose the tail of an answer that way.
• The usage block rides the final chunk (that is why stream_options.include_usage=True matters). A few underlying providers do not report usage on streams; in that case the fields are simply absent.
• The stream always ends cleanly. If the underlying model fails mid-stream, the router still sends a final finish_reason: "stop" chunk and [DONE] instead of leaving your client hanging on a truncated stream.

​

3. What you control (the request body)

​

model: "slng/auto" vs a named model

• slng/auto (recommended): SLNG routes the request using the model configuration set up for your org. This is what lets SLNG tune which model answers without you changing any code.
• A named model: if you have created a BYOK LLM in SLNG, you can pass the name of it to target that model directly.

​

4. Identity, agents, and sessions

• Internal auth + your org identity (managed for you). SLNG authenticates your API key and resolves your organization context. You never set this yourself, and there is no body field for it.
• Agent scope — the X-Slng-Agent-Id header. Send this on every request. It names the logical agent a call belongs to, which lets SLNG apply the right per-agent handling and optimizations. Use a stable value per agent, the same one on every call that agent makes. Best practice: put a version or date suffix in the value (for example clinic-scheduler-v1 or clinic-scheduler-2026-07). Whenever you change that agent’s configuration in a meaningful way, most importantly its system prompt, bump the suffix (...-v2, a new date, etc.) so the new version gets a fresh identity. Reusing the old id after a prompt change means SLNG keeps treating it as the same agent, which can leave optimizations tuned to the previous version in effect. Keeping the id in step with your agent version avoids that. It is a request header, not a body field.
• Session scope — the X-Slng-Session-Id header. Send this on every request. It identifies a single call (conversation) so SLNG can track per-call state for session-aware features. Use a value unique to each call, like a UUID, and keep it the same across all the turns of that call. It is a request header, not a body field.

​

5. Per-call values (template_variables)

This is one of the most important integration steps in this guide. If your system prompt contains anything that changes from call to call, send it through template_variables. Do not render it into the prompt text yourself. When per-call values are baked into the prompt as plain text, every call looks slightly different to SLNG and it cannot apply its optimizations to your traffic properly. With placeholders + template_variables, SLNG sees your stable prompt and the per-call values separately, which is exactly what its optimizations need. The model sees the same final prompt either way, but the difference in the speed and cost SLNG can deliver for you is real.

# DON'T: build the prompt string yourself per call
{"role": "system", "content": f"You are calling {caller_name} in {city}."}

# DO: keep placeholders in the prompt, send the values separately
{"role": "system", "content": "You are calling {{caller_name}} in {{city}}."}
# ...with, in the same request:
# "template_variables": {"caller_name": "Rajesh", "city": "Mumbai"}

resp = client.chat.completions.create(
    model="slng/auto",
    messages=[
        {"role": "system", "content": "You are calling {{caller_name}} in {{city}}."},
        {"role": "user", "content": "hello?"},
    ],
    extra_body={
        "template_variables": {"caller_name": "Rajesh", "city": "Mumbai"},
    },
)

{
  "error": {
    "message": "Missing required template variables: appointment_time, city",
    "type": "invalid_request_error",
    "param": "template_variables",
    "code": "missing_template_variables"
  }
}

Watch out for literal double braces. Any {{...}} in your system prompt is treated as a variable reference. If your prompt contains a literal {{ for some other reason (a code sample, a templating example), it will be read as a placeholder and trigger a missing_template_variables 422 unless you supply a matching value. Avoid stray double braces in prompts you do not intend as variables. If you have a live integration that cannot avoid them, SLNG can put your org in a lenient mode where un-supplied placeholders are left as-is instead of 422ing (ask SLNG; see section 10).

​

Limits and errors

• The slng_config object must stay under 256 KB when serialized; larger returns a 400.
• A config that fails validation returns a 400 starting with invalid slng_config: and a description of what is wrong. Your credentials are never included in these messages.
• Sending slng_config as anything other than a JSON object (a string, a list) returns a 422 with code invalid_slng_config.
• Sending it before SLNG has enabled it for your integration returns a 400 inline slng_config is not enabled.

​

Related