Integration guide

​

Endpoint and authentication

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

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

from openai import OpenAI

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

​

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},
)

• Reasoning blocks and control tokens are removed for you. If your model emits a visible reasoning block (<think>, <thought>, <thinking>, <reasoning>) or a stray control token (</s>, <|im_end|> and similar), the router strips it before the chunk reaches you, so your TTS never reads it aloud. Setting slng_pure_proxy suspends this.
• All answer content arrives before the finish_reason: "stop" chunk, so stopping there is safe.
• The usage block rides the final chunk. That is why include_usage matters.
• The stream always ends cleanly. If the model fails mid-stream, the router still sends a final finish_reason: "stop" chunk and data: [DONE], so your client is never left hanging.

​

Available parameters

​

slng/auto vs a named model

​

Required fields

• Agent ID names the logical agent a call belongs to, and scopes its cache. Use a stable value per agent. When you change that agent’s prompt in a meaningful way, give it a fresh ID, for example clinic-scheduler-v2, so answers produced under the old prompt are not reused.
• Session ID identifies a single call. Use a value unique to each call, like a UUID, and keep it the same across all turns of that call.

​

Reading the response

​

Response caching

​

What SLNG does not store

• Any reply containing a number, in any script. A number is usually specific to one caller or record, so identifiers, prices and dates are never cached.
• Personal information, such as names, addresses and emails.
• Any reply carrying a placeholder the router did not fill in itself.

​

Per-call values (template_variables)

# 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"}

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

# Write the steering value into the prompt text.
{"role": "system", "content": "Reply to the caller in Spanish."}

# The reply language decides what the answer IS, not what it says.
{"role": "system", "content": "Reply to the caller in {{session_language}}."}
# "template_variables": {"session_language": "Spanish"}   # <-- wrong field

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"
  }
}

​

What belongs in template_variables

• Do carry personalization values that get spoken or echoed in the conversation: the customer’s name, the agent’s name, the company name, an appointment detail rendered as text.
• Don’t carry values that steer or change the content of the answer itself: the response language, a plan or tier that changes which policy is described, a region that changes which rules apply.
• The language case deserves spelling out. A language variable is fine when it is just text to be said, for example the agent confirming “So your preferred language is {{language}}, correct?” during the call. It is not fine when it controls the language the model answers in: two callers who chose different languages would share one cached answer, and one would hear the wrong language.

​

BYOK Context Router (slng_config)

​

The configuration shape

resp = client.chat.completions.create(
    model="slng/auto",
    messages=[{"role": "user", "content": "Hello"}],
    extra_body={
        "slng_config": {
            "tiers": {
                "1": [
                    {
                        "model": "gpt-4o-mini",
                        "weight": 100,
                        "endpoint": {
                            "url": "https://api.openai.com/v1",
                            "api_key": "sk-...",   # YOUR provider key, not your SLNG key
                        },
                    }
                ]
            }
        },
    },
)

​

Supported providers

{
  "model": "my-azure-gpt4o",
  "weight": 100,
  "endpoint": {
    "provider": "azure",
    "url": "https://my-resource.cognitiveservices.azure.com/",
    "api_key": "...",
    "azure_deployment": "gpt-4o-deploy",
    "api_version": "2024-12-01-preview"
  }
}

​

Limits and errors

• The slng_config object must stay under 256 KB when serialized; larger returns a 400.
• A configuration that fails validation returns a 400 starting with invalid slng_config: and a description of the problem. Your credentials never appear 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.

​

Shadow mode