Skip to main content
Every request carries a Bearer token. Which token depends on which route. The middleware is scoped to exactly the prefixes each route file owns, so ingest’s auth is never shadowed by a broader wildcard.

​
Ingest keys

The key is hashed with SHA-256 and looked up against api_keys, which yields exactly one MCP id. That is where the payload lands — no value in the request body selects an MCP, so telemetry cannot be posted into someone else’s account by any means. Resolutions are cached in memory for five minutes so ingest never costs a database round trip per batch. Misses are cached for 30 seconds, so a misconfigured client cannot hammer the table. Revoking a key clears the cache immediately. A revoked or unknown key returns 401.

​
Supabase access tokens

Verified against the project’s published JWKS, and checked for issuer, audience and algorithm (ES256) as well as signature. A valid signature alone only proves the project minted the token, not that it was minted for this API. Your account and role are derived from the token, never from the request. Read Roles and permissions for what each role may do.

​
Your first request settles your account

Account resolution runs before every account-scoped route, not only on a write. If you have no membership yet:
  • an invitation exists for your address → you claim it, joining that account with that role
  • nobody knows you → a new account is created and you become its owner
This is why a fresh user who signs in and only reads gets real data rather than a wall of 404s.

​
Getting a token

There is no client-credentials flow and no personal access token. The dashboard obtains a token through Supabase magic-link sign-in and sends it on every request. For automation, the MCP endpoint is the supported path — it is OAuth, so nothing is copied and nothing is leaked.

​
Failures

A 404 for another account’s resource is deliberate. MCPulse never confirms that an id exists outside your account.