Keys and consent
LinkRunway separates client telemetry, trusted backend activity, and assistant access. Use a different credential for each integration boundary.
| Credential | Where it belongs | What it permits |
|---|---|---|
lr_pk_… publishable key | Browser or mobile app | Client routes and unverified, non-financial events |
lr_sk_… server key | Your backend secret manager | Trusted events and /v1/server/links |
lr_mcp_… MCP token | Your MCP client's protected configuration | Scoped tools in one workspace, until expiry or revocation |
| Console session | Signed-in LinkRunway console | Interactive workspace administration subject to role, verification, and MFA |
REST authorization
Send Authorization: Bearer <key> on each request. Use HTTPS. Never place credentials in query strings, source control, screenshots, support tickets, browser bundles, or public agent prompts.
Keys select their own workspace. An X-Workspace-Id header cannot move a key into another workspace. A revoked key or suspended workspace fails authentication. MCP tokens do not authenticate the REST API, and REST keys do not authenticate MCP.
The client SDK rejects a server key in browser and React Native environments. That check is a safeguard, not permission to package a server key elsewhere. All mobile apps must use publishable keys.
Consent and identity
Construct client SDKs with consent disabled until your consent flow grants permission. consent: true is a required assertion on tracking, resolution, and matching requests; it is not a consent dialog or a substitute for your own consent records.
Publishable events cannot establish canonical customer identity or verified revenue. Authenticate the customer in your backend and send their stable ID using a server key. Minimize metadata: prefer internal identifiers over email addresses or other personal data.
The SDK clears its local attribution and pending state when consent is withdrawn. This does not delete events already received by LinkRunway. Use your workspace's privacy process for stored data requests.
Rotate credentials
Create a replacement key, update your backend or client deployment, verify delivery, then revoke the old key in the console. Client deployments may take time to reach installed users; plan that rollout explicitly. If a secret is exposed, revoke it immediately and review affected activity.
MCP tokens expire after 24 hours. Issue a fresh token for a new setup session and revoke it when finished. Issuing a new token does not revoke older tokens automatically.
Browser access
SDK routes allow browser requests without cookies. Server administration and console routes are not a general browser API. CORS is not authentication and does not make a server key safe in a browser.
Continue with the API overview, MCP connection guide, or security guide.