For most internal scripts, a Platform API key is the shortest setup. Use an OAuth
client_credentials automation when your backend needs short-lived bearer tokens. It has no
redirect URI, human consent step, or refresh token.
Register in the company dashboard
- Select the company and open Settings → Platform API & MCP → Clients. In the new design
system, open Settings → API & MCP → Clients.
- Create a My company automation client.
- Enter a name and explicitly select the permissions it needs, such as
campaigns:read.
You need credential-management access and permission to grant every selected scope.
- Save the client ID and one-time client secret in your server’s secret store.
Public Dynamic Client Registration (POST /register) does not authorize company machine
access. Human OAuth consent also does not authorize client_credentials. Create the machine
app through the dashboard; an unapproved client receives unauthorized_client.
Request a token
Set SIDESHIFT_CLIENT_ID and SIDESHIFT_CLIENT_SECRET from the dashboard, then send:
The response contains access_token, token_type, expires_in, and scope. Use the returned
scope set, which can be narrower than the requested set if the creator’s access changed.
Store the token privately as SIDESHIFT_ACCESS_TOKEN and call:
Request another token when it expires. Do not attempt a refresh-token grant for this flow.
Never put the client secret in browser code, mobile apps, source control, or logs.
Access and lifecycle
New dashboard automations stay bound to the selected company and the creator’s current
permissions. Both token issuance and resource requests enforce that limit. Removing the
creator’s membership stops the automation; register a replacement under an authorized owner
before deprovisioning its creator when continuity is needed.
Editing scopes cannot grant beyond the manager’s own access. A manager cannot take over or
rotate the secret of a broader app. Scope reductions narrow already-issued tokens; scope
increases require a new token. Deleting or suspending the app invalidates future resource
requests using its tokens. Secret rotation prevents future authentication with the old secret;
it does not by itself revoke already-issued access tokens.
Machine tokens do not carry child delegation. For one credential across agency children, use
a delegated Platform key or human OAuth connection.
Existing company-bound machine apps created before creator-bound authorization keep their
company binding. No re-registration is required just to retain that existing setup.