Skip to main content
Every request carries a workspace API key. The key does two jobs: it authenticates the caller, and it selects the workspace, which is why no endpoint takes a workspace id.

​
Sending the key

Send it as the x-api-key header:
A bearer token is also accepted, if that suits your HTTP client better:
Both are equivalent. If both are present, x-api-key wins.

​
Creating a key

1

Open Integrations

In DMLY, go to Configurations → Integrations and select the REST API tile.
2

Create a key

Give it a name describing what will use it: “Zapier”, “Website form”, “n8n”. The name is how you will recognise it later when revoking.
3

Copy it now

The key is shown once. DMLY stores only a SHA-256 hash of it, so it cannot be retrieved or emailed to you afterwards.
A key grants full access to everything in its workspace. Treat it like a password: keep it server-side, never commit it, and never put it in browser or mobile app code where a user can read it.

​
Rotating and revoking

Create the replacement key first, deploy it, then revoke the old one. Revocation takes effect immediately and any caller still using the old key starts getting 401. DMLY stamps last_used_at on every authenticated request, so you can tell whether a key is still in use before retiring it.

​
When authentication fails

The two 403s are authorisation, not authentication: the key is fine, the workspace behind it is not. Only suspension produces a 403. A workspace that is merely past due, or whose subscription has lapsed, keeps its API access; billing states are settled in the dashboard, and cutting integrations off mid-dunning would be worse than the problem it solves. See Errors for the full list.