API keys

An API keyAPI keyA credential that authenticates calls to the Dime.Scheduler API. The preferred way to integrate over the deprecated JWT flow. is a long-lived secret that proves a process (not a person) has permission to call the Dime.Scheduler API. They are the simplest of several authentication options the API supports, which is exactly why they fit the cases where simplicity matters most: a back-office connector that wakes up every hour, a CI job that pushes setup changes, a script that pulls a daily report.

For anything user-facing - a web app where individual users sign in, an interactive tool - OAuth is the better choice. API keys cannot represent a specific person; they represent the integration as a whole. If multiple humans need different permissions or you need to know who did something, reach for the authentication options on the user side instead.

Creating a key

Global administrators can create a new API key from the API key setup page:

1. Open the API keys page from the admin menu.
2. Click New and give the key a recognisable name (the calling system, the script, the integration).
3. Pick an expiration date. Short-lived keys are safer; rotate them on a schedule that fits your security policy.
4. Click Generate. The full key is displayed once.

warning

The full key value is only shown the moment it is generated. Copy it into your secret store immediately - there is no way to retrieve it again afterwards. If the key is lost, revoke it and issue a new one.

Using a key

Send the key in the X-API-KEY header of every request - pass the raw key value, with no Bearer prefix, no quotes, no whitespace:

X-API-KEY: <your-api-key>

curl --header "X-API-KEY: YOUR_API_KEY" https://api.dimescheduler.com/...

The same header is used by the public API, the MCP server, and every supported SDK (.NET, JavaScript, Python).

Keeping keys safe

A leaked API key gives the holder everything the integration can do, for as long as the key lives. The safer you can make that surface, the better:

• Store keys in a secret manager (Azure Key Vault, AWS Secrets Manager, environment variables in a protected CI runner) - never commit them to source control.
• Use one key per integration. Rotation and revocation become surgical: when a script is decommissioned, revoke just its key, not everyone else's.
• Set an expiration. Even production keys should expire; an expiring key forces rotation discipline.
• Revoke immediately on suspected leak - delete the key from the API keys page and issue a replacement.