There are two ways to let something outside Tamaat call your API. Every plan has the first; plans with Tamaat Server add the second.
Make it available outside Tamaat
Every API has a web address from the day it is created: https://api.tamaat.com/«name». On the Use tab, under Endpoints, turn on Available outside Tamaat and the address starts answering.
Callers send a key with each request, in the x-api-key header. You create keys under Keys:
- A Website key works only from the websites you list, so it can sit in a page's JavaScript.
- A Server key works only from the addresses or ranges you list, for a job or a backend.
Each key has its own requests-per-minute rate. Store the secret when a key is created: it is shown once, and can only be rotated, not recovered. Rotating replaces the secret at once; revoking stops the key for good.
The address also serves the API's OpenAPI document at /openapi.json, and opening the address in a browser shows a reference page with a Try it console. Both are readable without a key, so an integrator can see what to send before you give them one.
Turning the switch off stops the address answering. Keys and the address are kept, and turning it back on restores them.
When the same API is also published to Tamaat Server, Server's environments get their own formal addresses (https://api.tamaat.com/«organization»/«environment»/«name»/…) and their own consumer keys. The regular address keeps answering your keys from the current index, and once a Production environment serves the API it is labelled Non-production. Nothing passes from one to the other.
If your organization has Tamaat Server, its Admin decides whether members may use this switch, under Sharing policy in organization settings.
Publish it to Tamaat Server
Publish it
"Publish to Server" publishes your product to the org's Non-production environment. The dialog tells you exactly what will happen: "Cuts release v«N» into Non-production. Production is unaffected until an admin promotes it."
Give it a release note saying what changed — you'll want it later.
Whatever you edit in the workspace afterwards doesn't touch what you just published; it goes into your next release.
Promote it to Production
Promotion is the only way work reaches Production, and your organization can protect it.
If you don't hold the role Production requires, the console tells you: "Production is protected — promoting requires the «role» role." Use "Request promotion" with a comment, and an admin who does hold it can "Approve" or "Reject".
With "Protect Production" switched on, everyone requests and a second admin approves — "Production requires promotion by approval — request it and another admin can approve."
If a promotion turns out badly, "Rollback" puts the deployment back on an earlier release exactly as it was.
Issue keys to your consumers
Consumers authenticate with consumer keys, issued under Environments. Two things to tell them:
- A key works in one environment only. A test key will never reach Production — that's the point of it.
- Store the key when it's created. It can't be shown again, only replaced.
After promotion
A promoted product can also be made callable by AI agents — see Expose Tools to AI Agents.