REST API References

MemberPass exposes a versioned REST API at https://api.memberpass.net/v1. Every mutation the creator dashboard can perform is also reachable through the API, scoped by Sanctum personal access tokens.

Shape at a glance

• Base URL — https://api.memberpass.net/v1
• Authentication — Authorization: Bearer mpt_live_... (Sanctum personal access token, minted at /settings/tokens)
• Tenant scoping — every token carries a mandatory scope:team:<uuid> ability and optional scope:project:<uuid> entries; the server resolves the team from the token, never from the request body
• Mutations — POST / PATCH / PUT / DELETE all require an Idempotency-Key header; successful 2xx responses are replayed for 24h under the same key
• Errors — uniform envelope { "error": { "code", "message", "docs_url", "remediation", "request_id", "fields"?, "context"? } }
• Rate limiting — 300 requests/min and 10,000 requests/hour per token, plus endpoint-specific buckets
• Pagination — list endpoints return a data array; most accept a limit query parameter (documented per endpoint). See Pagination.

Who this is for

Core concepts

• Authentication — minting tokens, the bearer header, and scope tuples.
• Abilities — the 65 ability strings that gate every endpoint.
• Tenancy and scopes — how scope:team and optional scope:project tuples combine.
• Idempotency — structuring retries so you never duplicate a mutation.
• Rate limiting — per-token and per-endpoint buckets + Retry-After semantics.
• Pagination — how list endpoints return data today.
• Errors — every error code with HTTP status, remediation, and recovery hints.
• Versioning and deprecation — the v1 contract and how breaking changes are announced.
• OpenAPI specification — the auto-generated machine-readable spec.

Agents first

The API contract is designed for LLM-driven clients. Every error carries a docs_url and a remediation string so agents can self-correct without a round-trip to documentation. The same ability catalog backs both the REST API and the MCP server — an ability you grant a token once works across both transports.

Versioning

Breaking changes are never introduced within a major version. Additive changes (new fields, new endpoints, new error codes) can appear at any time. See the versioning and deprecation policy for the full contract.