Manage365 Docs

API keys

MSP-scoped API keys let you drive Manage365 from your own scripts, CI pipelines, n8n/Zapier flows, or anything that can send a Bearer token. Keys sit in the same Authorization header as the portal's JWT session — the guard routes on the token prefix.

Creating a key

Settings → API keys → Create key. You'll pick:

  • Name — shown on the keys list. Use something that describes the automation, e.g. "CI pipeline" or "n8n tenant sync".
  • Permission — Read-only (GET only) or Read/write. Keys can only hold permissions the creator held at creation time, so an L3 creating a key can grant up to L3 scopes.
  • Expires in — days from now, 1–365. Leaving blank is supported but not recommended.

The plaintext key is shown once in a reveal dialog. Paste it into your secret store immediately — we only keep the argon2id hash at rest.

Using a key

Attach it as a Bearer token:

curl https://api.manage365.com.au/api/v1/tenants \
  -H "Authorization: Bearer m365_pk_<your-key>"

All requests go through the same rate limits + RBAC as a JWT session — if your L3 creator couldn't do it, neither can the key.

Read-only enforcement

Read-only keys get rejected by the guard on any non-GET verb with a clear 401 message. This is a belt-and-braces check on top of the permission filter — it means even if a key had USERS_CREATE in its scope, a POST /users with that key would still be blocked.

Revoking

Revoke from Settings → API keys. Revoked keys stop authenticating within one request (the guard hits the DB on every call). The audit log records who revoked which key and when.

Security notes

  • Keys never expire by default unless you set a duration.
  • The first 12 characters (prefix m365_pk_xxxx) are visible server-side so you can identify keys without re-revealing the secret.
  • No IP allowlisting yet — planned but not shipped. Use network- level controls on your side if you need them.
  • Usage count + last-used timestamp shown on the keys list so you can spot abandoned keys.