Choose how to authenticate
OAuth 2.1 & MCP
RecommendedScoped read and write access across the full platform. Register an app, request only the capability scopes you need, and act on behalf of a tenant. Also exposed as an MCP server.
API key
SimplerA header key from Settings → Integrations. Fastest way to start, but the surface is narrow and almost entirely read-only.
Skeleton page — the prose here is a first pass. Both references in the sidebar are
generated from the production specifications and are accurate.
The practical difference
The two surfaces are not the same API with different credentials. The API-key surface is read-oriented: of its 24 operations, 19 areGET. Only five write anything —
POST /posts/exportPOST /programs/{id}/invitePOST /invoices,POST /invoices/{invoiceId}/send,POST /invoices/{invoiceId}/void
Agency (parent) accounts can pass
scope=agency on the API key’s analytics and posts
endpoints to aggregate across the parent agency and every subaccount.OAuth 2.1
Access is granted through a standard OAuth flow:1
Register a client
Use Dynamic Client Registration to obtain a
client_id — and, for confidential clients,
a secret.2
Request authorization
Use the authorization-code grant with PKCE (
S256). The user sees a consent screen and
picks the company (tenant) and scopes to grant.3
Exchange the code
Trade the code at the token endpoint for a short-lived bearer access token and a refresh
token.
4
Refresh
Use the refresh-token grant. Refresh tokens rotate on every use.
MCP server
The same OAuth-scoped capabilities are exposed through a remote Model Context Protocol server atPOST /api/mcp, using the Streamable-HTTP transport. An AI agent can operate a
SideShift company through MCP tools instead of raw HTTP calls.
Connecting a client. Point any MCP client at https://app.sideshift.app/api/mcp. It
authenticates with the same OAuth 2.1 flow above — there is no MCP-specific auth scheme.
Tokens minted for MCP are multi-audience, so a single token works for both /api/oauth/v1
and /api/mcp. An unauthorized request gets a 401 with a WWW-Authenticate challenge
pointing at the RFC 9728 protected-resource metadata, so compliant clients can auto-discover
the authorization server.
What you get. Every capability scope maps to tools, mirroring the REST surface plus a
whoami tool. Read scopes expose read-only tools. Write and sensitive tools carry a
confirmation guardrail in their description. The claim-link capability is available as the
create_quickpay_claim_link tool.
Sandbox and sensitive operations
Test and sandbox grants can exercise reads and safe writes, but requests that move money or trigger outbound side-effects — payouts, sending invoices or messages, external re-scrapes — are rejected. Money-moving endpoints and campaign analytics-history validation/import requests require anIdempotency-Key.
Sensitive MCP tools are rejected for sandbox and test grants, and can be disabled globally
with the MCP_SAFE_MODE server flag.
Coverage
Campaigns and programs are the same concept; the OAuth spec names them campaigns, the API-key spec names them programs.
The API-key spec exposes 8 tags. The OAuth spec exposes 38.