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
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.