Create keys, decide where they are allowed to run, hand scoped temporary keys to partners, and rotate any of it without redeploying your product.
No key yet? Create an account — a sandbox key is waiting in your dashboard.
Key type decides where a request may come from. It does not unlock or withhold features — your plan, credits and permissions still decide what can run.
Runs the full set of features enabled on your account from anywhere — local tools, preview builds, live apps, and the MediaSFU sandbox.
Identical features, tighter blast radius: browser requests are accepted only from the HTTPS domains you have registered.
Hand a partner or a short-lived job a key that expires on its own and can only call the operations you grant it.
Registering domains for a production key takes a minute in the dashboard — and it is what stops a leaked key being useful anywhere else.
Generate a key in the dashboard and pick its trust boundary — sandbox for building, production for live traffic.
Register the domains a production key may be called from, and scope disposable keys to the operations they actually need.
Send one header. The same credential pair authenticates rooms, recordings, SIP, translation and AI agent endpoints.
Regenerate on a schedule, or the moment a key is exposed. Revoking a disposable key takes effect immediately.
Creating a room is the entry point for everything on MediaSFU — meetings, calls and AI agents all start here.
curl -X POST https://mediasfu.com/v1/rooms \
-H "Authorization: Bearer yourUsername:yourApiKey" \
-H "Content-Type: application/json" \
-d '{
"action": "create",
"userName": "host",
"duration": 30,
"capacity": 5,
"eventType": "conference"
}'Never ship a key in front-end code or commit one to a repository. Read it from an environment variable or a secrets manager.
Build and stage on a sandbox key, run live traffic on a production key, and never mix the two inside one application.
Plan a regular rotation for production keys — every 90 days is a sensible default — and regenerate immediately if one leaks.
Keys you have stopped calling are pure exposure. Turn them off, and review domain lists and permissions periodically.
The origin policy, not the feature set. A production key accepts browser requests only from the HTTPS domains you have registered; a sandbox key is not tied to registered domains. What your account can run is still decided by your plan, credits and permissions.
Into a single Authorization header, as your username and key joined by a colon: Bearer apiUserName:apiKey. Usernames are 6 to 32 characters, and the key itself is 64 characters.
Yes — that is what disposable keys are for. You choose the type, the domains, the operations it may call, and how many days it stays valid. Revoke it at any time and it stops working immediately.
Rotation affects new API requests, so roll the new value out to your servers before retiring the old one. Test the rotation on a sandbox key first, and keep the procedure written down.
Yes. Request allowances are tied to your plan tier and are shown alongside your keys in the dashboard, together with how many keys that tier allows.
Your keys, allowed domains and disposable keys all live in one place in the dashboard. SDKs, quickstarts and endpoint references live in the developer portal.