Every request to the Management API needs an API key. There are no unauthenticated endpoints and no public data.How it works#
Send your key in the X-API-Key header on every request:There's no scheme prefix, no OAuth flow, and no token exchange step. The key goes in the header as it appears in your dashboard.Getting your key#
API keys are generated per server from the NotifyMe dashboard. Open the server you want to manage, go to the API section, and generate a key.Your key is shown once, at the moment you create it. Copy it straight into wherever it's going to live. There's no way to view it again later, so if you lose it your only option is to generate a new one, which invalidates the old one immediately.
What a key can reach#
A key is bound to a single server. It can read and modify the accounts, embeds, and bot styles belonging to that server, and nothing else.This is why server_id is required on every endpoint. The parameter and the key have to agree. Passing a server_id your key isn't bound to fails, even if you own that server too. Managing several servers means holding several keys and picking the right one per request.Because a key maps one to one with a server, rate limits are counted per server. Two processes sharing the same key draw from the same allowance, so a bulk import running alongside a dashboard sync will hit the limit sooner than either would alone.Managing many servers multiplies your throughput, since each server has its own key and its own allowance. It doesn't raise the ceiling for any individual server.
When authentication fails#
Every authentication failure returns 401 Unauthorized. There are three of them:| Message | Cause |
|---|
Missing header: 'X-API-Key' | No key was sent. Check the header name and that your client or proxy isn't stripping it. |
Invalid header: 'X-API-Key' must start with 'nme_' | Something was sent, but it isn't shaped like a key. Usually a truncated copy and paste, or an empty environment variable resolving to a blank string. |
Unauthorized: The 'X-API-Key' header provided is not valid for this Discord server | The key is well formed but doesn't grant access to the server_id you passed. Either it belongs to a different server, or it has been replaced by a newer key. |
They use the standard error shape:{
"status": false,
"error": "Unauthorized: The 'X-API-Key' header provided is not valid for this Discord server"
}
server_id, and that it hasn't been replaced since.Authentication never returns 403. If you see a 403, it's the account limit, not your key.Replacing a key#
Generating a new key takes effect immediately and the old one stops working at once. With one key per server there's no overlap period, so plan for a short gap:1.
Pause anything that calls the API for that server.
2.
Generate the new key in the dashboard.
3.
Update it wherever it's stored.
4.
Restart and confirm with a GET /accounts call.
Keeping your key safe#
Server side only. Anything running in a browser, a mobile app, or a desktop client ships its key to whoever is using it. Treat a key in client code as already public.Use environment variables, not source files. Add .env to .gitignore before the first commit, not after.Keep keys out of logs. Redact the X-API-Key header in request logging, and remember that errors from HTTP libraries often include the full request when you print them.What someone with your key could do: read every account, embed, and bot style on that server, change where notifications go, edit or delete them, and trigger test notifications into your Discord channels.What they could not do: read your Discord messages, touch roles or members, or reach any other server, including ones on the same account. 