Review access for each action: reads require matching permissions, record changes need previews and retry keys, and sends also require an active owner-reviewed policy. Keep consent, suppression, licensing, and jurisdiction checks in the review.
What are the risk tiers?
| Tier | Actions | Control |
|---|---|---|
| R0 | workspace.context, workspace.capabilities | Scope workspace:read. Always listed when the scope is granted. |
| R1 | companies.*, trade.*, contacts.*, leads.list, campaigns.list | Matching read scope and workspace access. |
| R2 | leads.create, campaigns.draft | Creation scope, dry_run preview, idempotency_key required for an actual write. |
| R3 | email.send, sms.send | Send scope, active owner-reviewed policy_id, dry_run preview, idempotency_key required for an actual send. |
Use tools/list to discover the tools available to your connection. Availability depends on the granted permissions and workspace access. Start with read scopes; ask a workspace administrator to review missing access rather than requesting broad permissions.
How do standing policies and reviews work?
Before enabling sends, have an owner review the audience, sender, message claims, consent, suppression, applicable jurisdictions, licensing, and budget caps. Use an active standing policy_id for permitted sends and preview with dry_run: true. A standing policy may authorize multiple sends; it does not mean a person approves each message individually. Pause work when eligibility or authorization is unclear.
How should dry runs and idempotency keys be used?
- Send
dry_run: truefirst for every R2/R3 action. The server validates scopes, policies, and arguments without writing records or sending messages. - Generate one UUID
idempotency_keyper intended write and reuse it across retries. A repeated key returns the original result instead of creating a duplicate lead, draft, or send. - Never generate a new key when retrying a timed-out write. Store the key beside the
request_idin your own logs. - Required for an actual write or send; reuse the same UUID when retrying the same action with unchanged arguments.
What quotas apply?
Request and usage limits depend on workspace access and the action. Check current usage with your workspace administrator. For quota_exceeded, honor Retry-After and any returned reset time, then retry with bounded backoff. Do not use parallel retries, additional clients, or new policies to evade limits.
quota_exceeded includes reset_at and retry_after. Honor Retry-After and retry with bounded backoff. Do not fan out parallel retries against a 429.
How do you revoke access and review activity?
- Revoke at
POST /oauth/revokeor delete the OAuth client in Settings → Integrations. Revocation stops both MCP and REST agent calls for that token. - Review workspace audit events for policy reviews, sends, and policy changes.
- Check daily and window usage before raising limits or adding a new client.
- Rotate any token that appeared in a log, screenshot, or ticket. Never send the token to support; send the redacted
request_id, timestamp, tool name, and error code.