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. Then choose its REST API access: Full access, Only the areas I choose (each area set to read, or read and change), or no REST access. The dialog also asks for its AI assistant access.
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 made with Full access can reach everything in its workspace (so can any key made before permissions existed). Give a key only the areas it needs. 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 403s are authorisation, not authentication: the key is real, but either the workspace behind it cannot use the API or the key lacks a permission. A workspace that is merely past due keeps full API access, because a grace period still counts as paying. Once a subscription or trial has actually ended, every request fails with 403 This workspace has no active subscription., reads included, until it is paid again. See Errors for the full list.