SLNG

SLNG Documentation Audit

One-line summary: a fast-moving voice-AI gateway with a respectable Mintlify docs build, undermined by a broken agent-discovery directive on every page, a 500-ing model catalogue, a homepage curl example that uses undocumented values, and a thicket of contradictions between marketing, pricing, and reference docs.

1. Every docs page directs agents to a 404 (critical)

Location: Top of every page on docs.slng.ai (verified on /getting-started.md, /protocols.md, /voice-agents.md, /websockets.md, /changelog.md, /region-override.md, /pronunciation-dictionaries.md, /dashboard/api-keys.md, /sdks/index.md, /unified-api/overview.md, etc.)

Problem: Every Markdown page begins with this directive:

"## Documentation Index — Fetch the complete documentation index at: https://docs.slng.ai/llms.txt — Use this file to discover all available pages before exploring further."

That URL returns HTTP 404. The file that actually exists is https://docs.slng.ai/llms-full.txt. Neither subdomain serves llms.txt (the marketing-site equivalent at https://slng.ai/llms-full.txt also 404s).

Consequence: Every Claude Code/Cursor/Copilot session that reads a SLNG doc is told, first thing, to go fetch a file that doesn't exist. The agent either gives up on indexing or wastes a tool call. The whole point of having an llms-full.txt at all (which SLNG does, and it's quite good) is defeated by the directive pointing the wrong way.

The fix: Either (a) serve llms.txt as an alias/redirect to llms-full.txt, or (b) update the per-page directive across the docs build to point to /llms-full.txt. This is a one-line template change in the Mintlify build.

2. The /models page on the marketing site returns HTTP 500 (critical)

Location: https://slng.ai/models

Problem: Scrape result:

"500 — Internal Server Error."

This is the primary "Model Catalogue" link advertised in the top nav of the marketing site (the very first link after the logo).

Consequence: Evaluators clicking the hero nav land on an error page. The homepage promises "30+ models" — when a prospect tries to verify which models, the page is broken. Looks unmaintained at the most visible URL on the site.

The fix: Restore the page or redirect /models to https://docs.slng.ai/models (which loads fine).

3. ElevenLabs is promised in the Unified API but absent from the supported-models list (critical)

Location: /unified-api/overview.md and /unified-api/models-supported.md

Problem: The Unified API overview opens with:

"swap Deepgram, Rime, ElevenLabs, Cartesia, and more by changing the URL."

The supported-models page meta-description repeats the same promise:

"Full list of TTS and STT models reachable through the SLNG Unified API — Deepgram Nova and Aura, Rime Arcana, ElevenLabs, Cartesia, Sarvam, and more."

But the page's actual TTS accordion list contains: Rime Arcana v3, Rime Arcana v1, Deepgram Aura 2, Cartesia Sonic 3, Murf Falcon, KugelAudio Kugel, Soniox TTS v1, Sarvam Bulbul v3. No ElevenLabs entry. The llms-full.txt index does reference tts-elevenlabs.oas and an eleven-flash-v2-5 page, but neither is surfaced on the supported-models page that the overview links to.

Consequence: A developer choosing SLNG specifically to "swap in ElevenLabs" reads the catalogue, sees no ElevenLabs accordion, and can't tell whether (a) it's been silently removed, (b) it lives at a URL the catalogue forgot to link to, or (c) the marketing copy is aspirational. Agents picking models from this page will never select ElevenLabs even though the OpenAPI spec exists.

The fix: Add the ElevenLabs accordion with model identifiers and host columns, or remove ElevenLabs from the lede on both pages. If the model is in private beta, label it that way explicitly.

4. The homepage's flagship curl example uses an undocumented header and an undocumented region (critical)

Location: https://slng.ai/ (hero "in-region compute" code block)

Problem: The second curl example on the homepage reads:

curl -X POST https://api.slng.ai/v1/tts/slng/rime/arcana:3-en -H "Authorization: Bearer YOUR_KEY" -H "X-Region: eu-west-1" -d '{ "text": "Hello from production", "speaker": "astra" }'

Two problems in one snippet:

1. The documented region-pin header is X-Region-Override, not X-Region (per /region-override.md).
2. eu-west-1 is not a documented region — the documented EU region is eu-north-1. No row in the regions table has eu-west-1.

Consequence: This is the very first compliance-themed code sample a buyer sees. An agent or developer pasting it as-is will either silently get default routing (because X-Region is unknown and ignored) or hit a routing error — exactly opposite to the message of the surrounding "audio stays in-region" copy. Compliance is the strongest pitch in SLNG's marketing; the homepage example contradicts the docs that back the pitch.

The fix: Change the header to X-Region-Override and the value to a documented region (eu-north-1 for EU). Regenerate the homepage code samples from the same source as the reference docs so they can't drift.

5. The Getting Started example mislabels voice as model (critical)

Location: /getting-started.md first TTS curl example

Problem: The example puts aura-2-thalia-en into the model field of the request body:

curl https://api.slng.ai/v1/tts/slng/deepgram/aura:2-en … -d '{ "model": "aura-2-thalia-en", "text": "Hello from sunny Barcelona!" }'

But aura-2-thalia-en is documented elsewhere as a voice, not a model. The Unified API parameters page lists it under "Deepgram Aura 2 voices" alongside aura-2-asteria-en and aura-2-celeste-es; the Unified API overview separately notes that "the model is inferred from the URL path. Do not include a duplicate model field in the request body unless an endpoint reference explicitly requires it."

Consequence: This is the literal first request a new user types. They learn the wrong mental model on page one — that model is the voice field — and propagate that mistake to every later snippet. Agents using this page as a template will generate working-looking JSON that confuses the API and other readers downstream.

The fix: Change the field from model to voice in the getting-started example, matching /pronunciation-dictionaries.md and the parameters-coverage page. Add a one-line note: "The model is set by the URL path; voice selects the speaker."

6. The same TTS model has three different identifiers across docs (significant)

Location: /voice-agents.md, /protocols.md, /examples/tts-websocket.md, /websockets.md, /unified-api/overview.md

Problem: For Deepgram Aura 2 English (SLNG-hosted), the docs use three different identifier shapes:

So depending on which page you copy from, the model token is one of: slng/deepgram/aura:2-en (URL paths), aura:2-en (some init payloads), or aura:2 (other init payloads). The /unified-api/overview.md note says "Do not include a duplicate model field in the request body unless an endpoint reference explicitly requires it" — which only deepens the confusion about whether the field is required, optional, or harmful when present.

Encoding contracts also fork between pages for the same surface: /unified-api/parameters-coverage.md declares STT encodings as linear16, mp3, opus; /api-reference/tts/rime-coda/coda-indonesian-ws.md declares mp3, wav, pcm, linear16, ulaw for that endpoint's TTS encoding; the STT WebSocket example only ever uses linear16. No canonical reference reconciles these.

Consequence: Copy-paste the WebSocket example as-is and the init message's model field may or may not match what the server infers from the URL. For agents parsing examples, there's no deterministic rule to derive one form from another, and no rule that says "if init.model conflicts with the URL, which wins?"

The fix: Pick one canonical identifier shape (slng/deepgram/aura:2-en) and use it everywhere. State explicitly whether init.model is ignored, validated against the URL, or required. Publish a single "canonical encodings" table per modality and link every per-endpoint reference at it.

7. Region vocabulary forks between gateway and Voice Agents (significant)

Location: /region-override.md, /voice-agents.md, /integrations/overview.md

Problem: Two parallel region vocabularies exist:

The /region-override.md page closes with a NOTE acknowledging the split — "The two are not interchangeable. The agent region ap-south, for example, routes to the gateway region ap-south-1, but you set it through a different field." The Voice Agents table further says the agent region applies its routing through either X-World-Part-Override or X-Region-Override depending on the row (Europe → X-World-Part-Override: eu; Asia → X-Region-Override: ap-south-1), with no explanation of why the underlying override differs by region.

Separately, /integrations/overview.md documents a ?region= / ?world-part= query-parameter escape hatch for Cognigy and Jambonz that does not appear on /region-override.md, so a developer reading the region reference page has no way to know the option exists.

Consequence: Developers building agents that also call gateway endpoints directly (e.g., for batch TTS) will set the wrong region value silently. Compliance-driven customers — who are the entire pitch of the regions page — get the worst of this, because nothing fails loudly; calls just route to the wrong sovereign hub.

The fix: Either unify the vocabulary (agent region values should equal the gateway region IDs they map to), or publish a canonical mapping table at the top of both /region-override.md and /voice-agents.md showing agent-region ↔ gateway-region ↔ world-part for every row, plus an explanation of why some agent regions route via world-part and others via region. Cross-link the query-parameter override from the regions reference.

8. Pricing page's STT/TTS provider lists don't match the docs catalogue (significant)

Location: https://slng.ai/pricing vs https://docs.slng.ai/models/index.md, /unified-api/models-supported.md, and /api-reference/speechmatics/create-batch-job.md

Problem: The pricing page lists these providers:

• STT: "Gradium, Deepgram, Speechmatics, AssemblyAI, Soniox, Whisper, Gladia, pyannoteAI, Voxtral, Savram AI"
• TTS: "Gradium, Rime, Deepgram, Cartesia, InWorld, Savram AI, Soniox, KugelAudio, MURF.AI"

The docs Model Catalog only documents these STT providers: Deepgram, Soniox, Sarvam AI, Reson8. And these TTS providers: Rime, Deepgram, Sarvam AI, KugelAudio, Murf, Cartesia, Soniox. Gradium, AssemblyAI, Gladia, pyannoteAI, Voxtral, and InWorld appear nowhere in the docs. Reson8 (which is in the docs) doesn't appear on the pricing page. "Savram AI" appears to be a typo for "Sarvam AI."

Speechmatics is a special case: the pricing page lists it, the catalog does not, and yet /api-reference/speechmatics/create-batch-job.md shows slng/speechmatics/batch:15.0.0 as the default model_code on the Batch API. So a Speechmatics backend is shipped and live, but the Model Catalog hides it.

The marketing homepage advertises "30+ models" and the regions page claims "100 Proprietary & Open Source models" — meanwhile /models/index.md opens with "11 TTS models and 7 STT models from 8 providers." That's 18 models and 8 providers documented, against 30+/100 promised.

Consequence: A buyer who picks SLNG because it lists Whisper or AssemblyAI on the pricing page will not find those endpoints in the catalog. A Speechmatics customer doing the opposite — reading the catalog first — will conclude the backend isn't available, even though it's the Batch API's default. The "100 models / 30+ models / 18 models" tri-claim is the kind of contradiction that gets quoted back in a procurement review.

The fix: Make the pricing page's provider lists a generated subset of the docs catalogue, with each entry linking to the model's reference page. Add Speechmatics to the Model Catalog (with the Batch API link). Reconcile the homepage and regions page model counts to match the catalogue. Fix the "Savram" → "Sarvam" typo.

9. API key "rotation" copy contradicts itself (significant)

Location: /dashboard/index.md vs /dashboard/api-keys.md

Problem: The dashboard index card promises:

"API Keys — Create and rotate API keys used to call SLNG."

The actual API Keys page contradicts this directly:

"Keys cannot be rotated in place."

The body then walks through a three-step manual create-replace-delete dance.

Consequence: A security or platform engineer designing key rotation believes (from the card) that SLNG has a rotate-in-place mechanism. They build their secret-management runbook around rotate(key_id) semantics, then discover the actual flow requires coordinating every caller off the old key before the old key is deleted — and that deletion is immediate ("Any request still presenting the deleted key will start failing with 401 Unauthorized"). That's a meaningfully different operational story.

The fix: Update the dashboard card to say "Create and delete API keys, or roll a key by creating a new one and retiring the old." Add a one-liner to /dashboard/api-keys.md reassuring the reader that deletion is the supported rotation primitive, and link to the three-step procedure.

10. Pricing page concurrency, encoding, and rate copy is inconsistent (significant)

Location: https://slng.ai/pricing

Problem: Several internal contradictions in a short page:

1. Pro concurrency is described two ways:
   • "When using SLNG STT & TTS Models — Concurrency | from 5 agents"
   • "Agent Concurrency — Hobby: 1 — Pro: 6 included — Enterprise: Custom"
2. The "Hobby" row in the Additional Agent Concurrency table contains literal Unicode replacement glyphs: "Hobby: ��" — likely a broken em-dash or "N/A" character.
3. STT row reads "STT — any model (+ US$ 0.0033 / per agent min)", TTS row reads "TTS — any model (US$ 0.0033 / per agent minute)". The + on the STT line suggests an additive surcharge, but the page's headline rate is also $0.0033 — readers can't tell whether STT costs $0.0033 (same rate) or $0.0066 (base + STT).
4. "Noise Cancelation" is missing an l.

Consequence: Pricing pages are where deals close or stall. A 20% ambiguity on per-minute cost ($0.0033 vs $0.0066), combined with a 5-vs-6 agent concurrency mismatch, gives procurement teams reasons to ask painful questions. The mojibake (��) reads as a stale or untested page.

The fix: Replace the + US$ 0.0033 with an unambiguous total (or explicitly: "$0.0033 base + $0.0033 STT = $0.0066/min"). Pick 5 or 6 for Pro concurrency. Replace the corrupt glyphs. Fix the spelling.

11. Pages referenced in the changelog are missing from llms-full.txt (significant)

Location: /changelog.md vs /llms-full.txt

Problem: The changelog links these pages, which are reachable on the site but absent from the docs index file that agents are told to consume:

• /api-reference/stt/whisper-large-v3/whisper-large-v3-http (referenced from the May 16, 2026 entry)
• /api-reference/tts/rime-coda/coda-indonesian-ws (page is live)
• /api-reference/tts/eleven-flash-v2-5/elevenlabs-flash-v2-5-ws (the tts-elevenlabs.oas spec exists in the index but the per-endpoint page does not)
• The "Rime Arcana v1" link on /models/index.md resolves under /api-reference/tts/rime-arcana-v2/arcana-v2-english-ws (v1 vs v2 mismatch in path)

Consequence: Agents fed llms-full.txt as "the complete documentation index" build a model picker that omits Whisper Large v3 and Rime Coda. A user asking Claude Code "transcribe this with Whisper" gets told the model isn't supported, even though the endpoint is live and shipped recently. Path mismatches like rime-arcana-v2 containing the "v1" reference also break direct-fetch lookups.

The fix: Re-generate llms-full.txt from the same source as the site navigation, so every shipped page is indexed. Add a CI check that fails if a page is reachable but absent from the index file (or vice versa). Rename arcana-v2-… to arcana-v1-… or vice versa to match the human-facing label.

12. Hub count contradicts itself on the homepage (significant)

Location: https://slng.ai/ and https://slng.ai/regions

Problem: The homepage shows two counts on the same screen:

• "13 hubs — 30+ models, in-region execution" (hero metric strip)
• "11 sovereign hubs. Physical GPU hardware" (In-region compute callout)

The regions page reinforces 11: "11 Soverign Voice Hubs" (also misspells "Sovereign").

Consequence: "How many regions can I deploy to" is a load-bearing question for any compliance-driven buyer evaluating SLNG. Two numbers on a single page with a 2-hub gap is the kind of detail that lands in an evaluator's "concerns" column.

The fix: Pick a number. Reconcile homepage, regions page, region-override docs (which list 7 specific region IDs), and the Voice Agents region table (which lists 3) so a reader can map "N hubs" → the actual list of region IDs. Fix the "Soverign" typo.

13. The WebSocket auth-via-query-parameter escape hatch is hand-waved (significant)

Location: /websocket-guide.md, /unified-api/overview.md

Problem: The WebSocket integration guide says:

"Some WebSocket libraries don't support custom headers; pass the key as a query parameter (?token=YOUR_KEY) if needed."

The Unified API overview confirms the issue:

"The browser WebSocket API does not support custom headers. Pass the API key as a query parameter or use a server-side WebSocket client."

But the parameter name diverges between pages: the guide uses token, the overview just says "as a query parameter." No reference page for any endpoint documents the param. No mention of whether the value is the raw key or a derived token.

Consequence: Browser-side voice agent demos are a huge use case for SLNG (Voice Agents has a whole /agents/embed-web page). A developer building one will try ?token=…, ?api_key=…, ?authorization=…, hit 401, and have no docs to consult. Worse, embedding raw API keys in browser query strings is a security risk the docs should address (key scoping, ephemeral tokens) and don't.

The fix: Document the exact query-parameter name on the WebSocket reference and the embed-web page. Strongly advise against putting long-lived API keys in browser URLs and document the ephemeral-token flow (the web-sessions endpoint already returns a livekit_token, so a parallel concept presumably exists for direct gateway WS — say so).

14. The two SDK env vars are documented as a known split, but every page still picks one (significant)

Location: /sdks/index.md, /sdks/cli.md, /sdks/skills.md, /sdks/javascript.md, /sdks/python.md, /agents/livekit-plugin.md

Problem: The SDKs landing page acknowledges:

"The CLI reads VOICEAI_API_KEY. The JS and Python SDKs default to SLNG_API_KEY but accept an explicit apiKey option. Set both to the same value if you plan to use multiple tools side by side."

Then each downstream page picks its own:

• CLI: VOICEAI_API_KEY
• Agent skills: VOICEAI_API_KEY
• JS SDK: SLNG_API_KEY
• Python SDK: SLNG_API_KEY
• LiveKit plugin: SLNG_API_KEY

The package name compounds the confusion: SDKs install as voiceai-sdk (PyPI/npm), CLI is voiceai-cli, repo is slng-ai/sdks, brand is SLNG.

Consequence: Anyone using more than one SDK has to maintain two env vars with the same value. AI coding agents picking up partial setups (e.g., the Claude Code skill is installed but the JS SDK is added later) silently break — the skill works, the SDK throws "missing api key" with an unhelpful message. Telling users to "set both" is a workaround masquerading as documentation.

The fix: Standardize on SLNG_API_KEY everywhere (matching the brand), and have the CLI/skills accept VOICEAI_API_KEY as a deprecated fallback with a warning. Rename voiceai-sdk and voiceai-cli to slng-sdk / slng-cli (the npm name voiceai-sdk already conflicts with the brand on every page that documents it).

15. Latency claims contradict across pages with no shared definition (significant)

Location: /index.md, /protocols.md, homepage hero

Problem:

• Welcome page: "Low Latency - Sub-200ms for TTS, real-time for STT"
• Protocols page: HTTP "200–500 ms", WebSocket "Sub-100 ms"
• Homepage hero: "~50% Turn latency — p99 latency benchmarks"

Three numbers (sub-100ms, sub-200ms, "~50%") with no shared definition of what is being measured (first-byte? full-utterance? round-trip? relative to what baseline?).

Consequence: Latency is the headline reason to choose this category of product, and "category-defining marketing claim that the docs can't substantiate" is the kind of thing that turns up in a vendor RFP. A buyer comparing SLNG against Cartesia or Deepgram has no apples-to-apples number to anchor on; an engineer building a demo doesn't know whether to budget 100 ms or 500 ms; and an agent reading the docs to recommend SLNG finds three conflicting claims at three nav depths.

The fix: Define each latency metric ("time to first audio frame," "transcription final after speech end," etc.), publish one canonical p50/p95/p99 table per metric/region/model, and link the homepage hero, welcome page, and protocols page at that table.

16. The LiveKit plugin's deprecated alias has no migration deadline (minor)

Location: /agents/livekit-plugin.md

Problem:

"slng.STT also accepts a legacy api_token= alias, but it is deprecated — use api_key in new code."

No version, date, or removal target is given.

Consequence: A team maintaining a LiveKit Agents deployment has no way to schedule the migration, so they either fix it immediately (when they could have batched the work) or ignore the deprecation indefinitely until a release breaks them.

The fix: Add the version that introduced the alias, and the version (or date) it will be removed. Pattern: "api_token was renamed to api_key in livekit-plugins-slng 0.3.0 and will be removed in 1.0 (planned Q3 2026)."

What they do well

• The Mintlify build itself is clean, with consistent navigation and OpenAPI specs published for every major surface (gateway.oas, batch.oas, agents.oas, etc.) — agents and humans can find structured contracts when the page-level docs go silent.
• Error responses on at least the dispatch-call endpoint document 400/402/422/502 with concrete detail examples — far above the typical bar.
• A real changelog with API version tags (v0.48.1, v0.46.0, v0.44.1…) and meaningful entries on breaking region changes (e.g., "Aura 2 Spanish drops the na world part") — exactly what agents need to migrate.

Top 3 recommendations

1. Fix the agent-discovery directive and the homepage's broken curl on the same pass. Alias llms.txt to llms-full.txt (or update the template), and regenerate the homepage code samples from the docs source so X-Region: eu-west-1 cannot ship again. These two together are the first thing every agent and every evaluator sees.
2. Reconcile the model universe across marketing, pricing, and reference docs. Pick one number, one provider list, one identifier shape per model — and surface Speechmatics in the catalog if Batch ships it as the default backend.
3. Unify the region vocabulary. The split between us-east-1 (gateway) and us-east (agents), plus the mix of X-Region-Override vs X-World-Part-Override per agent region, makes the compliance pitch — SLNG's strongest pitch — the part hardest to verify from the docs alone.