Skip to main content
Plainrouter uses a per-workspace Server secret for the Signals Conversion API, a Workspace key for production MCP tool calls and the Actions API, a Management key for developer management operations, and a separate OAuth management credential for account discovery. Public MCP discovery requires no credential. The unauthenticated sandbox is retired. Retrieving a production prompt requires a workspace key. The Signals REST endpoints, TypeScript, Python, Ruby, Go, and the CLI are six interfaces to the same Conversion API and all use the same Server secret.

Does email verification affect my keys?

Yes. Workspace and Management key authentication checks the issuing person’s verified email as well as current access. An email change pauses that person’s protected account and agent access until the new address is verified. Verify the current address before replacing a seemingly valid key; verification cannot restore expired or revoked credentials. Manage verification and optional two-factor sign-in.

Which credential should I use?

These credentials are not interchangeable. The Conversion API rejects Workspace keys and OAuth management credentials. MCP rejects Server secrets, Management keys, and OAuth management credentials.
Never paste any Plainrouter credential into an agent prompt. Inject credentials through your server-side secret manager or the client’s protected credential configuration.

How do I authenticate the REST API?

Send the Server secret as a bearer token to the server-side Conversion API at https://plainrouter.com/api/v1:
PLAINROUTER_TOKEN must contain the Server secret. A missing or invalid secret returns HTTP 401. For action proposals, status, policy, and decision receipts, use the separate Actions API authentication and account-selection steps.

Where do I manage the Signals API secret?

Sign in as the workspace owner, select the intended workspace, and open Settings → Workspace → Server secret after Signals is configured. This secret authenticates Signals REST, SDK, and CLI calls; workspace keys have their own Settings → Workspace keys page.

Rotate without interrupting your integration

  1. Choose Rotate and copy the replacement immediately into your server-side secret manager. The replacement is shown once.
  2. Update each integration and verify a read request, such as the event-list request above, with the replacement. Your current secret continues working while a replacement is pending.
  3. Choose Confirm after all integrations use the replacement. Confirmation retires the previous secret.

Discard a pending replacement

If you lose the replacement before finishing rotation, choose Discard, then confirm Discard pending replacement. This cancels only the pending secret; your current secret keeps working. Cancel or Escape closes the dialog without discarding anything. Anything already using the pending replacement will stop authenticating after you discard it. Restore those integrations to the current secret before discarding, or prepare to update them during a new rotation. Then choose Rotate again, save the new replacement, verify it, and Confirm when ready. The page cannot reveal a lost secret again. After discarding, Replacement pending disappears and Rotate becomes available. Verify a read with the current secret if you need to confirm integration access. Discard does not change the publishable browser key or the current server secret.

Revoke a lost or exposed secret

Choose Revoke and confirm the warning. The current secret and any pending replacement stop working immediately, and Plainrouter issues a new secret. Copy it once, update your integrations, and verify authentication again. Expect old credentials to return 401. Use Discard when only the pending replacement should be canceled. Use Revoke when the current secret must stop working, including when it is exposed. Keep secrets out of browser code. The Signals snippet uses a publishable key instead.

How do I authenticate the TypeScript SDK?

Install @plainrouter/sdk@0.10.1, then configure the generated client explicitly:
The TypeScript SDK does not read environment variables automatically. Your server must pass the Server secret through signalTrackerSecret. The property keeps its pre-collapse name for compatibility.

How do I authenticate the Python SDK?

Install plainrouter==0.10.1, then create a client with the Server secret:
The Python SDK requires Python 3.11 or newer. Each operation module also exposes an asynchronous asyncio method.

How do I authenticate the Ruby SDK?

Install plainrouter-sdk 0.6.1, then create a client with the Server secret:
The Ruby SDK requires Ruby 3.2 or newer. The client sends the supplied tracker secret as a bearer token and does not read environment variables automatically.

How do I authenticate the Go SDK?

Install github.com/plainrouter/sdk-go@v0.7.1, then create the client with the Server secret:
The Go SDK requires Go 1.23 or newer. Keep the Server secret in server-side credential storage.

How do I authenticate the CLI?

The CLI uses the same Server secret and retains the name “tracker token” in its login prompt. Store it through the hidden login prompt for an interactive workstation:
For CI or an ephemeral shell, inject PLAINROUTER_TOKEN through the job’s secret manager before running the command. The CLI does not expose a --token option. An environment token takes precedence over the locally stored token.

What can I discover without a credential?

https://plainrouter.com/mcp permits public protocol discovery, tool/resource/prompt listing and reads of static ui:// app shells. Retrieving a prompt with prompts/get, calling a tool, and reading account data require workspace authorization. Account-scoped reads additionally require access to the selected account. The old unauthenticated sandbox returns HTTP 410 with sandbox_retired for API and MCP protocol requests. Move existing integrations to authenticated access; anonymous discovery or a browser redirect is not a substitute for a successful workspace read.

How do I authenticate Plainrouter MCP?

Configure an MCP-compatible client with these exact connection values: A workspace owner or member creates a key in Settings → Workspace keys for one or more selected workspaces, a requested Read or Write tier capped by their role in each workspace, and a 30, 90, or 365 day expiry. The selected set is fixed at creation. Call list_workspaces to inspect the authorized set and effective tiers. Include workspace_id on subsequent MCP calls when more than one workspace is available. For account-scoped work, call get_account_state first. Confirm the returned workspace and Meta ad account before continuing. For installation before connecting Meta, use get_install_instructions and confirm its workspace. Signals reads use the workspace’s bound Meta destination; Actions and creative calls require account_id when eligible-account selection is ambiguous. Older account-bound keys cannot override their binding. See account selection.
A Write or Admin token can submit governed proposals, but it does not bypass policy, the selected approval mode, provider verification, or account restrictions. A proposal-producing MCP request is not a direct Meta write.

Where do I create a Management key?

Open Settings → Management keys, enter a name, select a 30, 90, or 365 day expiry, and choose Create key. Copy it once into developer-side secret storage. Use Delete to remove an obsolete key. The table shows creation, last use, expiry, status, and Created by; a team owner can manage team members’ keys where permitted. Management keys authenticate the four management operations below under the key owner’s current membership and role. Give agents a workspace key for MCP instead. A Management key is not the OAuth management credential described below and cannot authenticate the agent-context route, Signals Conversion API, or human approval pages.

How do I use the management API?

Use a Management key to list accessible workspaces and create, list, or revoke your own workspace keys. These operations do not create workspaces or change ads. The /tokens paths retain their API name even though the dashboard calls the credentials workspace keys. Before starting, create a Management key, load it into PLAINROUTER_MANAGEMENT_KEY through your secret manager, and confirm your current membership in the workspace’s team. Do not use a workspace key or browser session as the management API credential. Use the base URL https://plainrouter.com/api/v1 for these paths:

1. Find the workspace

Choose the returned workspace’s integer id. It is different from the advertising-account ID used in MCP calls. The examples below use workspace ID 42; replace it with your selected ID.

2. Create a workspace key

The new key is scoped to the submitted workspace set and has no fixed ad-account binding. For example, add "workspace_ids":[42,43] to authorize those two workspaces. Both must be accessible to the issuer. Do not send an account ID when issuing it; follow account selection when using it. The response contains a secret. Capture token directly into protected client configuration or secret storage and retain access_token.id for lifecycle operations. Plaintext is returned only on creation; the response uses Cache-Control: no-store, private. Keep it out of terminal recordings and request/response logs. A repeated POST creates another key; do not treat issuance as an idempotent retry. Call list_workspaces with the issued execution key to inspect effective workspace tiers. The creation response’s legacy access_token.grant_id identifies the primary grant; it does not enumerate every selected workspace’s grant. An owner can inspect each workspace’s Grants section. Verify the new workspace key with get_account_state, supplying account_id when required. Confirm the returned workspace and Meta ad account before any proposal. Use the new workspace key for that MCP call, not the Management key.

3. List or revoke your workspace keys

Each access_tokens item includes id, name, tier, abilities, last_used_at, expires_at, revoked_at, and the historical rotated_from_token_id. Listing does not expose another member’s keys or recover a secret. Use the token record’s integer id, not its plaintext value or grant ID, to revoke it:
Replace 123 with your key’s record ID. A successful response has no body. List again to verify revoked_at is populated. To replace a key, create and verify its replacement before revoking the old one; there is no rotation endpoint. Deleting or expiring a Management key does not revoke workspace keys it previously issued. Revoke each workspace key separately when access should end. Removing the issuer’s membership or reducing their role also changes what their credentials can authorize.

Why does a management request fail?

How do I use an OAuth management credential?

An OAuth management credential has one documented agent-facing use:
The route returns the approved read-only account-discovery context. The same credential cannot call MCP tools, Launcher imports, or other agent-authenticated routes. Use a separately issued Workspace key for MCP after discovery.

Why does a workspace request return 404?

On documented workspace-scoped machine routes, a missing, inaccessible or non-canonical workspace selector returns HTTP 404 with error.code: "api_route_not_found". A credential can be valid while the requested workspace is unavailable to it. This response does not reveal whether another workspace exists. Use the exact positive integer ID returned by discovery. Leading zeros, signs, spaces, decimal forms and booleans are not canonical workspace path IDs. A workspace_id query or body selector matters only on routes that read it; it cannot widen credential access. A foreign or malformed entry in a workspace_ids selection is a field-validation error rather than a way to enumerate workspaces.
  1. Confirm the route’s credential type and intended workspace locally.
  2. Copy the authorized ID from workspace discovery and check both the URL and any documented selector.
  3. Inspect the response code and body together. A 403 for an accessible workspace’s missing operation is different from workspace 404; an Actions receipt_not_available is a separate scoped response. Do not retry neighboring IDs or infer deletion from a generic 404.
The current public contract governs these server responses even if an older generated client describes a narrower error union. See Actions receipts and Workspace key access. MCP workspace selectors follow the same canonical-ID boundary. Pass the integer from list_workspaces; a boolean, padded or leading-zero value is not a valid alternative. Correct both tool arguments and documented query/header selectors. Workspace selection explains the scope rules.

Why does a dashboard URL reject my bearer token?

Dashboard settings and approval pages require a signed-in browser session. A valid Workspace key or OAuth management credential cannot replace that session, even with an active grant or Admin tier. On an accessible session route, a bearer header causes 401 even when a valid browser session cookie is also present. Remove the Authorization: Bearer ... header from browser-session requests; check any proxy or client that adds it automatically. Signing in again does not make a bearer header valid on a session route. If an automation receives 401 on a dashboard URL, check the requested interface before rotating credentials. Use the documented MCP or API operation with its matching credential, or sign in to complete the interactive action. For grant management, follow the dashboard revocation steps or the separately authorized revoke_grant MCP tool.

Which clients are available?

The REST contract and all five SDKs expose the signed Conversion API operations. The PyPI and npm CLI distributions expose nine commands and do not include an ingestion-verification command. Use REST, an SDK, or MCP for ingestion verification.

Which credentials must not be confused?

  • A Server secret cannot authenticate MCP.
  • A Workspace key cannot authenticate the Conversion API.
  • An OAuth management credential cannot authenticate MCP.
  • A browser session cannot replace an API or MCP bearer credential.
  • A same-origin Path B forwarding secret authenticates generated forwarding infrastructure only. It is not an API, SDK, CLI, or MCP credential.
  • Meta access tokens remain on the Plainrouter server. Do not place a Meta token in a Plainrouter client configuration.
For complete request and response fields, use the Conversion API reference. For token tiers and lifecycle, use Workspace tokens. For available agent tools, use the MCP tool reference. For machine discovery, start with the API resource index or the RFC 9727 API catalog.