Authentication
Every request needs the header Authorization: Bearer <token>. Other ways (token in the URL, in the body or as a cookie) are rejected — a token in the URL even explicitly with token_in_url_forbidden, because URLs end up in logs. A scheme other than Bearer (such as Basic) is answered with 401 invalid_authorization_scheme; a missing header with 401 missing_token.
Structure of a token
m2h_live_Ab12Cd34Ef56_Zt3q…(43 characters)| Part | Meaning |
|---|---|
m2h | fixed prefix (makes accidentally published tokens easier to detect) |
live | environment: live (production), stg (staging) or dev (development). A token only works in its own environment, otherwise the API answers with wrong_environment. Exception: test marks a sandbox token (see Sandbox), which works in every environment and only sees sample data |
Ab12Cd34Ef56 | public identifier — shown in the management app and in logs |
| last part | the actual secret; we do not store it, only an irreversible fingerprint |
Validity, expiry and revocation
Tokens are valid for at most 365 days (default 90). After expiry the API responds with token_expired — create a new token in good time and replace it in your program. A token can be revoked at any time under Administration → API access; revocation takes effect immediately.
Request log
Every request made with a token is logged for 90 days — time, method, path, status, error code, duration and IP address, never the token itself or request/response bodies. Rejected sign-ins with a known token ID (wrong secret, revoked, expired) appear as well. Administrators see the log per token under Administration → API access → History.
A token can never do more than its creator
On every request we additionally check the current permissions of the person who created the token. If that person loses a permission or their account is deactivated, the token stops working immediately (insufficient_permissions or invalid_token). For permanent integrations, create tokens with an account that will remain in place.