Authentication
Authenticate every Partner API request with an organization API key.
Every request carries an API key as a bearer token.
Authorization: Bearer mor_live_7f3c1a9e…A key belongs to the organization, not to the person who created it. It keeps working when that person leaves, and any admin of the organization can see it listed and revoke it.
Create a key
Open Settings
In Morphic Studio, open the organization dropdown (the Morphic logo, top-left) and select Settings.
Go to API keys
From the left sidebar, click API keys. The tab is visible to admins only.
Create the key
Click New key, give it a name you will recognize in a month, choose its scopes, and — if it should not live forever — an expiry.
Copy the secret
The secret is shown once. Morphic stores only a hash of it, so it cannot be shown again. Put it in your secret manager before you close the dialog.
Anyone holding the key can start runs that consume your organization's credits. Treat it like a password: never commit it, never put it in a browser, never send it over email or chat.
Scopes
A key holds only the scopes you gave it. A request outside them is refused with access_denied.
| Scope | Allows |
|---|---|
workflows:read | reading a workflow and the inputs it takes |
runs:write | starting runs, and registering and removing webhook endpoints |
runs:read | reading a run's status and its finished assets, and listing webhook endpoints |
A key can also be limited to specific workflows. Starting anything else is refused, and a run of anything else reads as not found, which is what you want for a key that lives in one integration.
Environments
The prefix says which deployment a key belongs to, so a leaked key is placeable at a glance. A key presented to the other deployment is refused.
| Prefix | Environment | Base URL |
|---|---|---|
mor_live_ | production | https://api.morphic.com/v1/partner |
mor_test_ | staging, for integration work; runs there are capped and the data is not yours | https://api.morphic.today/v1/partner |
Credit limits
Every key carries a ceiling on the credits it may spend, set by the admin who created it:
| Limit | Set? | Meaning |
|---|---|---|
| Total | always | credits the key may ever spend |
| Per day | optional | credits per UTC day |
| Per month | optional | credits per UTC month |
A day is a UTC day and a month a UTC calendar month. A charge that would take the key past one of its limits is refused with api_key_credit_limit_reached; the error's error_attributes.period says which limit (total, monthly or daily). That is a different condition from the organization being out of credits (credits_exhausted), and it is fixed differently: an admin raises the key's limit in Studio rather than topping the organization up. A start whose key has no room left is refused before anything is fetched.
A run started with a key keeps counting against that key even if somebody steps into the chat in Studio and takes it over. So the key's remaining budget is the budget for the whole run, not just its automated part.
Rotation
Rotate by overlap, never by gap: create the new key, deploy it, confirm traffic has moved, then revoke the old one. An organization may hold up to 10 keys that can authenticate at once, which is room for rotation without becoming a pile nobody is retiring.
Revocation bites within seconds. Runs already in flight finish and are still billed.