Workspace and access

Configure the environment your integration uses, grant the minimum required key role, and decide how you will observe usage and retain run data. These settings are workspace operations; they are separate from an agent's draft.

Production and sandbox

List environments identifies the production and sandbox tenants and the environment selected by your key. An admin can create the sandbox on first use. Sandbox members are shared with the organization, while agents, runs, secrets and phone setup belong to the selected environment.

Before running an example, check that your key is for the intended environment. A resource ID from another environment will not resolve. Phone trunks and numbers need setup in each environment where you use them. Run admission must also be enabled; a sandbox alone does not establish carrier routing or permission to place a call.

API keys and provider credentials

Create keys in Settings → API keys. Use a viewer key for read-only reporting, a member key for agent and run integrations, and an admin key for workspace setup. Each endpoint states its minimum role. Real outbound phone calls also require Can place calls on a member key (can_dial: true); admin keys can place calls, while viewers cannot. Store secrets in your secret manager and inject them on the server; do not place an API key in browser code.

API key creation and rotation return the secret once. Save it at creation; list operations return metadata. Revocation affects future access and can deny queued effects of runs started by that key. Coordinate rotation with the systems using it.

Provider credentials let your environment use its own model-provider key. Their read operations expose metadata. Read the endpoint's validation and deletion behavior before replacing a credential.

Members and secrets

An admin invites members and assigns roles. Review members and pending invitations periodically; revoke stale invitations and remove access when it is no longer needed. Keep service API keys separate from a person's login.

Agent action credentials, SIP passwords and webhook signing values belong in versioned secrets. The agent references a secret version; listing secrets does not expose the value. See Triggers and webhooks for integration setup.

Rates, usage and limits

Read your rate card and metered usage to understand the active pricing configuration. Budget and rate-card responses can report configured: false; do not treat that as zero cost. Usage can be incomplete while measurements are settling, so inspect the response's completeness fields.

A spending cap and a daily outbound call limit address different constraints. The budget concerns metered spend; the call limit concerns outbound calls. Concurrent run capacity is separate again. A refused run's error reason tells you which limit blocked admission. See API limits.

Alerts and delivery

Create alert rules for supported usage or run metrics, and configure destinations separately. Destination reads return metadata rather than credentials. Rule updates use revision checks: read the current rule before changing it.

If a delivery outcome is uncertain, inspect the latest delivery before acknowledging it. Acknowledgment allows the rule to fire again; it is not proof that an earlier notification arrived.

Retention and audit history

Read workspace settings to see the current retention policy before changing it. Retention updates require the expected version so concurrent administrators do not overwrite each other. Outputs removed by retention cannot be treated as pending; check their state when reviewing older runs.

Use the audit log to review workspace activity. Agent run transcripts, tool receipts and event timelines remain in the run API; the audit log does not replace those records.