What the gateway does, shown rather than described
Five task profiles behind one endpoint: text, text extraction from an image, image understanding and speech synthesis. Live demos on the page, with the failure modes named.
Everything below goes through one endpoint. Your code sends a task profile — text, extract, describe, speak — and which model and which provider answer is decided by the gateway, by its own routing rules.
This is not about saving lines of code. It is about a retired model, a raised price or a provider outage no longer being your incident: the route changes inside the gateway and your integration stays as it was. The cost of each request is measured on the way, not guessed afterwards.
POST /api/v1/…
- task profiles
- 5
- endpoints to integrate
- one
- fallback path
- yes
- model name in your code
- none
Four kinds of task, one integration
Text
service: textSummaries of a thread, classification of incoming requests, field extraction from an invoice or an email, a first draft answer written to your own rules.
Where it fails. It fails confidently on numbers and dates unless they are checked separately: the answer sounds equally firm whether it is right or wrong.
Text extraction
service: ocrText off an image as it stands: a receipt, an invoice, a screenshot, a page of a contract. Lines, lists and tables are preserved.
Where it fails. Handwriting, a photo taken at an angle and poor light are the three usual causes of divergence. Checkable fields — totals, reference numbers — deserve rules, not trust.
Image understanding
service: visionWhat is in the picture and what follows from it: condition of an object, completeness of a delivery, compliance with a requirement, a description for a catalogue.
Where it fails. The model tends to fill gaps with something plausible: if a detail is not visible, ask for it explicitly instead of expecting it to be noticed.
Speech synthesis
service: ttsText spoken aloud: announcements, notifications, a spoken FAQ, a draft voice-over.
Where it fails. Stress in unfamiliar names and abbreviations is not always right, and a question carries less intonation than a statement.
From code it is the same endpoint
One field changes — the task profile. Neither the model nor the provider appears in your code, which is why their turnover is not your problem.
Text
{
"service": "text",
"text": "Summarise this thread in five points"
}
Image
{
"service": "ocr",
"text": "Extract the text as it stands",
"images": ["<base64>"]
}
Speech
{
"service": "tts",
"text": "Your order is packed and waiting"
}
Access is granted one client at a time, after a conversation — there is no open sign-up. That is more honest than a "get your key" form with an unbounded queue behind it.
Try it here
POST /api/v1/probeYour text goes through the same gateway our products use. Which model answers is decided by a routing rule, not by this page.