Saltar al contenido principal

Authentication

The Midla Platform API authenticates with personal access tokens, sent in the Authorization header of every request:

Authorization: Bearer YOUR_TOKEN

There's no username/password authentication and no API key in the query string — every API request must carry this header with a token generated from the panel (see Getting started).

Scopes​

Every token is generated with one or more scopes — granular permissions that determine what that specific token can do. Assigning at least one scope is required when creating a token; there's no "full access" token.

Naming convention: {resource}:{action}. For example:

ScopeAllows
leads:readRead leads (GET /leads, GET /leads/{id})
leads:createCreate leads (POST /leads)
leads:updateUpdate leads (PATCH /leads/{id})

Each API module defines its own scopes — full details are in each module's reference.

Principle of least privilege

Assign each token only the scopes it actually needs. If your integration only reads leads, don't give it leads:create or leads:update. You can create separate tokens for separate purposes.

What happens if your token lacks the required scope​

If your token doesn't have the scope an endpoint requires, the API responds with 403 Forbidden:

{ "message": "Invalid ability provided." }

Check your token's assigned scopes from System → Integrations → API in the panel.

Expiration and revocation​

  • A token can have an optional expiration date (set when creating it). Without one, the token stays valid until manually revoked.
  • You can revoke a token at any time from the panel — revocation is immediate.
  • A revoked or expired token responds with 401 Unauthenticated on any request.

Multi-tenant: each token belongs to a single organization​

Tokens are specific to the organization (subdomain) where they were generated. A token generated on acme.web.midlaplatform.com won't work against another-company.web.midlaplatform.com. If you manage multiple organizations, you need a separate token for each one.

Administrator permissions​

Listing integrations requires view_any_core_integration. Activating/deactivating integrations and creating or revoking Platform tokens also requires update_core_integration. These panel permissions are separate from the scopes granted to the token for API requests.