Authentication
Every request authenticates with a bearer token. There is no signature step, no request signing, and no OAuth flow for server-to-server use.
Creating a key
Open API keys in the dashboard and create one. The plaintext key is displayed once and never again. Only a hash is stored, so a lost key cannot be recovered. Revoke it and create a replacement.
The prefix tells you which environment a key belongs to. Keys are prefixed mint_live_ for production and mint_test_ for testing.
Using the key
Pass the key as a bearer token in the Authorization header:
Authorization: Bearer mint_live_xxxNothing else is required for authentication. The key identifies both the account and the credit balance the request draws against.
Handling keys safely
Keep keys server-side. A key sent to a browser is a key anyone can read, and it carries your full credit balance with it. Load it from an environment variable rather than committing it to a repository.
# .env: never commit this file
DATAMINT_API_KEY=mint_live_xxx
curl -X POST https://api.datamint.xyz/v1/mint \
-H "Authorization: Bearer $DATAMINT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com/item/123"}'When authentication fails
Every authentication failure returns 401 with the error code unauthorized, and the response body is identical whether the key was missing, malformed, unknown, or revoked.
That uniformity is deliberate. Distinguishing “this key never existed” from “this key was revoked” would tell anyone holding a stolen key whether it had ever been valid. Do not build logic that depends on telling those cases apart. The API will not give you the difference.
A 401 means the key itself is the problem. A 402 means the key is fine but the credit balance cannot cover the request. See Errors for the full list.
At a glance
Need volume pricing or a custom parser?