Authentication
The partner API authenticates every request with an API key sent as a Bearer token. There are no sessions, cookies, or CSRF tokens to manage — each request carries the key.
API keys
Every account has a metered API key for best-effort rendering. Accounts with provisioned dinks (reserved render nodes) also receive a reserved API key for priority renders. The key you authenticate with selects how the job is handled:
| Key | Job type | Billing |
|---|---|---|
| Metered key | Best-effort renders, no SLA, subject to system load | Metered per rendered hour |
| Reserved key | Priority renders, claimed ahead of best-effort work | Covered by your provisioned dinks (flat monthly) |
Both keys are UUIDs tied to your account, for example:
3f8c1a2b-9d4e-4f6a-bc12-7e0a5d9c1234
A reserved request from an account with no provisioned dinks returns 403.
Treat your keys like passwords:
- Keep them server-side. Never embed a key in client-side JavaScript, mobile apps, or anything a user can inspect — anyone holding a key can submit billable render jobs on your account.
- Send them only over HTTPS.
- Store them in a secret manager or environment variable, not in source control.
Account activation
New accounts start in an inactive state. We reach out and activate your account before the API
accepts any requests — until then, calls authenticated with your key are rejected. If you have
signed up but your requests are returning 401, your account is most likely still pending
activation.
Sending the key
Pass the key in the Authorization header using the Bearer scheme on every request:
Authorization: Bearer YOUR_API_KEY
For example:
curl https://dinkem.gg/api/clips \
-H "Authorization: Bearer 3f8c1a2b-9d4e-4f6a-bc12-7e0a5d9c1234" \
-H "Content-Type: application/json" \
-d '{ "demo_url": "https://example.com/demo.dem", "steam64_id": "76561198000000000", "round": 5 }'
Once you can authenticate, head to Submitting Render Jobs.