Developer overview

The d5s developer surface is a beta HTTP API for operating workspace resources and following agent execution. The same core resources used by the app are available in the OpenAPI contract: projects, sessions, agents, automations, dashboards, files, connectors, skills, sharing, usage, and audit operations.

Beta boundary

The contract is currently beta. Use the generated OpenAPI description as the source of exact paths and schemas. Endpoint names, payloads, and authentication restrictions may change before a stable version is declared.

Reuse an agent's model settings

When creating an agent through the API, you can copy model settings from an active agent in the same workspace, including a shared Codex model choice. You need access to view and run the source agent. Workspace administrators manage shared Codex model choices.

The new agent keeps the settings copied at creation. Later changes to the source do not update it. Model copying does not copy instructions, connector access, or conversation history. Configure those separately. You cannot combine a model template with explicit model settings in the same request. Use the generated OpenAPI contract for the request field and supported errors.

Isolated development environments

If your workspace has access to coding environments, you can create a separate development environment for a conversation you own. These operations require an interactive user token, membership in the active workspace, and permission to run that conversation. Workspace API keys cannot operate them. Use the generated OpenAPI contract for requests, limits, and response fields.

Keep the environment ID and job IDs when submitting work. Read the same job to follow its progress or cancel it. If submission loses its response, inspect that job before deciding what to do; submitting the command under a new ID can execute it twice. An unknown environment state does not establish whether work started or finished.

Files in the development environment are temporary. Download changes or commit them to your repository before expiry or Stop. This environment does not automatically publish changes or grant access to your connected accounts. File transfers and HTTP previews return encoded content; render development previews in an isolated viewer. Browser cookies and app credentials are not part of the preview request. Live WebSocket previews are not exposed by these operations.

Stop requests shutdown. Read status until shutdown is confirmed; accepting Stop alone is not confirmation. If development access is disabled, you can still inspect status and request Stop for an environment you retain permission to control. Coding operations cannot create or operate a security testing environment.

Agent browser automation

Use Inspect and stop an agent browser to check an assigned browser and stop it after automated work. The guide explains administrator access, task ownership, and conflicts.

Discover saved session files

Use the generated OpenAPI contract to list a session's saved artifacts in pages. The listing requires access to that session. Saved versions remain available after working files expire. Listing or opening them does not resume the coding environment.

Supply sandbox credentials

If Link workspace secret is available, organization or workspace administrators can link a shared secret to an agent or project. Scripts receive it under the chosen environment name. Command requests do not include credential values. Rotation, expiry, and removal follow the sandbox credentials rules.

Use the generated OpenAPI contract for configuration and secret binding operations. Configuration responses expose names and status, with no credential values.

Workspace search

GET /api/v1/search searches the active workspace across sessions, agents, projects, automations, and dashboards. Agent matches use the agent name, persona, and description; only active agents are returned. An agent is represented once as an agent result rather than duplicated as its continuing session, and its id opens the agent resource directly. Matching, limits, and the complete response schema remain defined by the generated OpenAPI contract.

Workspace member directory

The member directory supports a team view of people assigned directly or through a group to the requested workspace. Organization-wide administrative access alone does not place a person on its team. The default directory continues to support mentions. Both views require an interactive user token and workspace access; the team view remains available when mentions are disabled. Use the generated OpenAPI description for the scope parameter, ranking, and response fields.

Project memory

GET /api/v1/projects/{project_id}/memory lists a project's memory entries with their versions. A member with project edit access can write one entry with PUT /api/v1/projects/{project_id}/memory/{key} or many with POST /api/v1/projects/{project_id}/memory/import. An import takes 1 to 50 entries. Each entry has a key, its content (16 KB or less), and an expected_version. Send 0 for a new key and the listed version for an existing key. The import checks every version before it writes. One mismatch returns 409 with the version_conflict code, and no entry changes. Keys are lowercase letters, digits, and underscores, 60 characters or less. Use OpenAPI for the exact schema.

Authentication and API keys

Workspace owners and admins create API keys in Settings → Workspaces → workspace name → Developers → API keys. New keys created there expire after 90 days by default; you can choose another expiry, including Never. The API keeps no expiry when expires_at is omitted. The secret is shown only when created. Store it in a secret manager; revocation takes effect immediately. API keys currently use wildcard workspace scope and act through the access of the user who created them. Some sensitive user-owned configuration writes, including agent autonomy and connector grants, require an interactive user token and cannot be performed with an API key.

Saved coding app listing, registration, and reopening require an interactive user token and access to the owning conversation. Saving or reopening additionally requires permission to run that conversation. Use the generated OpenAPI contract and client for the supported request and result shapes. Reopening cannot reclaim a browser controlled by another person.

MicroVM API operations require access to the owning conversation. Use the generated OpenAPI contract for current environment, command, file, and cleanup schemas. Workspace Targets and notes are optional text; they do not enforce network restrictions.

Browser profile management also requires an interactive user token and the caller's workspace permission; an API key cannot control a saved profile. When stopping a profile after automated work, supply the expected_generation from its current profile state. A changed generation returns 409 without stopping the newer controller. Read and review that state before retrying. Omitting the field keeps the ordinary Stop action available. Use the generated OpenAPI contract for the exact request schema.

Interactive sign-in starts at GET /api/v1/login/authorize. Browser clients can preserve navigation in state; native clients use the PKCE parameters in OpenAPI. Follow the published authentication contract for callbacks and account selection.

Region discovery and personal workspace creation are separate operations. GET /api/v1/users/me/regions returns available region labels without exposing account activity or memberships. A signed-in user can use POST /api/v1/users/me/claim-region in an eligible region to create or reuse a personal workspace. Use OpenAPI for the exact request and response.

The workspace update operation changes the display name without changing the workspace slug. It requires workspace Owner or Admin access through an interactive user token; workspace API keys cannot call it. Use the OpenAPI description for the current path, request schema, and generated client method.

Workspace deletion requires an interactive user. A workspace Owner or Admin can review the content counts and cancel a scheduled deletion. Only the current workspace Owner can request the email code and schedule deletion. The schedule request requires acknowledgment, the exact workspace name, and the emailed code. Content does not have to be removed first. The workspace stays available for 48 hours, and content added during this period is also deleted. Personal workspaces are protected. If cleanup cannot finish, the deletion status shows that it needs attention. Use the OpenAPI description for the exact paths and schemas.

Native account and notification operations

Native clients revoke their refresh token through the logout operation using the current access token and the refresh token in the request body. Use the generated OpenAPI contract for the exact request. The refresh token must belong to the signed-in user; repeating a valid logout is safe. A temporary failure is not confirmation that revocation succeeded. Browser cookie logout continues to work without that body.

Notification device registration and preference operations require the signed-in user's token, not a workspace API key. Registering a device does not subscribe it to every agent: agent preferences are explicit and require current access. Disable the device before discarding the credentials used to sign out.

The separate retirement operation accepts an opaque, device-bound proof when native authentication has expired. Treat it as a secret with one purpose: retiring that device's notifications. It cannot read preferences, register a device, subscribe to an agent, or authorize workspace work. Use OpenAPI for the current operations and generated request and response types. Failed notification retirement can be retried separately from interactive sign-in and local session invalidation. A stale retirement proof is not an authentication credential. If notification session verification is temporarily unavailable during refresh, interactive access can recover while notifications are disabled; enable notifications again after verification is available. Confirmed token revocation still rejects refresh.

Organization and workspace management

Workspace creation trims surrounding whitespace from the name. A blank name returns 422; provide a non-blank name before retrying. This applies to both personal-organization and organization-scoped creation. Use the generated OpenAPI reference for the current name limits.

The signed-in user has a self-scoped privacy read and update operation whose request contains only require_no_training. It cannot name another user. Organization Owners and Admins use the organization privacy update to set the same requirement for all members. Both operations return the stored preference, record changes in the audit log, reject unknown fields, and default to normal routing. Use the OpenAPI description for the exact paths, authentication requirements, and generated client methods.

The organization update operation changes the display name without changing the organization slug. It accepts a typed name of 1 to 255 characters, trims surrounding whitespace, and rejects unknown fields. Active organization Owners and Admins can call it with an interactive user token; ordinary members, non-members, and workspace API keys cannot. A successful change records an organization audit event. Use the OpenAPI description for the exact path, request schema, response, and generated client method.

Any active organization member can list the workspace portfolio. Owners and Admins see every workspace; other members see only the workspaces they belong to, and the search, pagination, and summary count only those rows. For members who are not Owners or Admins, the owner email and grant counts are null, and search does not match owner emails. The organization member list includes each member's workspaces (id, slug, and name); a member who is not an Owner or Admin sees only the workspaces they also belong to. Organization Owners and Admins can use the organization endpoints to create a workspace, transfer workspace ownership, and create, change, or revoke explicit user and group workspace grants. Organization Owners and Admins, plus Owners and Admins of the target workspace, can send a workspace invitation that grants the selected Member or Admin role in that exact workspace. Personal workspaces reject invitations. Active organization Owners and Admins are automatically Admins of every workspace in the organization, including workspaces created later. Plain organization membership does not grant workspace content access. These control-plane endpoints require an interactive user token; workspace API keys cannot call them. Use the OpenAPI description for the exact /api/v1/organizations/{organization_id}/workspaces paths and schemas.

Each workspace portfolio row includes aggregate member and agent counts. If the caller is also a member of that workspace, member_previews returns up to three people with canonical avatar state and agent_previews returns up to three agent ids and names. Both arrays are empty when the caller has no workspace membership. Organization Owners and Admins are Admins of every workspace in the organization, so they receive both previews. The member count includes these automatic Admins. The direct_grant_count does not include them. Compare each array length with its aggregate count to represent additional identities.

Organization model policy

The model policy is set once per organization and applies to every workspace in it. Organization Owners and Admins read and update it through GET and PUT /api/v1/organizations/{organization_id}/model-policy; other members cannot call the update operation. GET /api/v1/workspaces/{workspace_id}/model-policy stays available to any workspace member and returns that workspace's organization values; there is no workspace-level update operation. The response includes enabled models, the default model, reasoning defaults, the organization Fast preference, and effective model choices. Omitting the optional Fast preference on an update preserves its existing value. Model availability is derived from the organization's current plan and policy. Provider selection is not a client control. Use OpenAPI for the exact response fields and update schema.

Use the model-policy response as the source for enabled models, defaults, and effective selections. Catalog model preferences can include a stable family alongside the concrete model. A new turn uses the newest eligible version within that family, including for older saved catalog choices. When Fast is enabled, it uses that version's eligible Fast variant or its regular model. Running work and historical model and usage records keep their concrete version. Light, Medium, High, and Auto continue to follow current d5s selections on new turns. Free organizations can select the Light level; additional choices depend on the current plan and organization policy. A choice outside that policy is rejected. Do not hardcode a model list in an integration. Use the generated OpenAPI schemas for the optional family preference fields on model policy, agents, Project preferences, automations, dashboards, and chats.

If a selected model cannot run under the current plan and policy, admission is refused. Integrations must not implicitly select a different model or geography to bypass a refusal.

The organization member update operation also accepts a nullable whole-cent spend limit. A non-negative value sets the limit and null clears it. Organization Owners can update any member's limit. Organization Admins can update ordinary members, but cannot update themselves or another manager.

Personal workspace setup

A signed-in user can claim an available region to create or reuse a personal workspace. An optional name applies when creating it; a retry returns the existing workspace. Use OpenAPI for the supported choices and response fields.

Billing and entitlements

The organization billing summary and entitlement responses expose current seat quantities, prices, and feature keys. The summary also reports whether the consumer withdrawal action is available. The withdrawal read returns the server-owned eligibility or submitted acknowledgement. The preview operation renders the exact statement for confirmation, the submit operation accepts that statement with the consumer name, acknowledgement email, and a client idempotency key, and the acknowledgement retry operation never resubmits the withdrawal. These organization-scoped endpoints require an active organization membership, with billing administration restricted to Owners and Admins. Use the generated OpenAPI description for exact fields and Plans and credits for the commercial model.

A credit top-up checkout returns a redirect URL and Checkout Session id. An organization-scoped read reports whether that purchase has completed and the credited amount. Use the generated OpenAPI description for the exact response and polling contract.

If a Pro-to-Max upgrade request is interrupted, retry it for the same organization. A completed prior upgrade returns the existing result without charging again.

Start team creation in the chosen region's app or API. Draft, create, and activation operations stay in that region. A create request includes the team name, seat counts, and a client idempotency key, and returns a checkout URL. Review displayed prices and promotional terms before accepting a seats-on-joining offer. Reuse the same key when recovering an interrupted request; reusing that key with a changed seat mix is rejected, and an unresolved checkout may need support before another attempt. Activation reports subscription state and the first workspace when the caller can access it. These operations require an interactive user token. Use OpenAPI for exact fields, errors, and retry rules.

Activation shows the first workspace only to a caller permitted to open it. Other organization Owners and Admins can see subscription status. They are Admins of every workspace in the organization, so activation shows them the first workspace too. Creating another workspace requires an active team subscription.

If a team uses seats on joining, request an invitation seat quote before authorizing additional capacity. Only an organization Owner or Admin can authorize the joining charge and individual seat's monthly price. Sending records consent without charging; acceptance applies any needed seat before granting membership and the selected workspace access. Quotes and free reservations have separate deadlines, and an expired free authorization never becomes paid without new consent. Existing team members require no extra seat. Retry an interrupted acceptance as directed. If acceptance reports a pending billing result, wait or contact support before you change billing. Use OpenAPI for exact quote, invitation, and error contracts and Plans and credits for user-facing terms.

Preview a Word document

The Files API can return a PDF preview of an uploaded DOCX for an active workspace member. Use the generated OpenAPI contract for the multipart request, binary response, size limit, and errors. If the preview is unavailable, your integration can show a simplified preview or offer the original file for download. Preview form fields are read-only.

Temporary API unavailability

An API request can return 503 with Database is busy. Wait for the response's Retry-After interval before retrying. For writes, follow the endpoint's retry and idempotency rules. If the error continues, contact support with the request time.

Integration model

MCP authorization servers can identify the regional d5s OAuth client through the public GET /api/v1/oauth/mcp/client-metadata.json document. It contains the d5s client name, app URL, exact callback URI, and public-client grant metadata; it contains no workspace data, token, or client secret. Application integrations do not call this endpoint during ordinary workspace API use.

Native connector authorization

A signed-in native client can request mobile_launch: true from the regional POST /api/v1/oauth/{provider}/init operation. A workspace Owner or Admin must start the request. Send the workspace, connector, scope set, and a registered native return_to address. The response contains authorize_url and mobile_flow_id. Open the returned first-party regional URL in the system browser. The browser must sign in to the same d5s account that started the native request. The regional frontend preserves the launch continuation through login. It then sends the ticket to the user-authenticated POST /api/v1/oauth/{provider}/mobile-launch operation. The API checks the initiating account before consuming the ticket or setting callback proof. Only then does the browser open provider consent. The public launch GET only opens the first-party page. The ticket can be used once and expires; start a new request if it is unavailable. It does not grant API access.

The accepted return_to values are d5s://agents/new, d5s-preview://agents/new, d5s://oauth/callback, and d5s-preview://oauth/callback. Each requires mobile_launch. The return contains flow_id and either connected_credential or oauth_error. Match flow_id to mobile_flow_id before using the result. On success, read the returned credential in the same workspace and confirm its connector, purpose, and active state. Do not treat a return to the app alone as proof of a usable connection.

To reconnect, pass the exact credential_id; to add another connection, use create_new. These fields cannot be combined. A new custom MCP connection also needs its public HTTPS server URL. Reconnect uses the existing connection's saved URL. The OAuth callback is a browser return, not a Bearer-authenticated API operation; do not call it directly from a native client. Use OpenAPI for the current fields and errors. This is an API contract, not confirmation that every provider's native setup has passed an end-to-end test.

Workspace API requests use the v1 base path, a Bearer token, and the active workspace id:

curl "$D5S_API_URL/api/v1/projects" \
  -H "Authorization: Bearer $D5S_API_KEY" \
  -H "X-Workspace-Id: $D5S_WORKSPACE_ID"

A workspace connection is available to new and existing projects by default. A project can turn that connection off, and reconnecting the workspace account does not undo that choice. Use the public project connector operations to manage availability and follow OpenAPI for their request and response contracts.

Agent and project deletion returns 409 while a conversation run is active. Stop active runs before retrying deletion. External resource cleanup continues through the retained cleanup journal.

A basic chat integration follows this lifecycle:

1. Create a session with POST /api/v1/sessions. Omit project_id for standalone work, or pass a project id to reuse that project's context.
2. Upload any session files and retain their ids.
3. Send work with POST /api/v1/sessions/{session_id}/messages. The response returns a durable turn_id, admission status, and optional queue position.
4. To compact eligible older context without a normal assistant run, call POST /api/v1/sessions/{session_id}/compact while the session is idle. A queued response includes the command turn id; nothing_to_compact means no model call was admitted.
5. Read lightweight GET /api/v1/sessions/{session_id}/metadata and a recent GET /api/v1/sessions/{session_id}/events page. Events within each page are chronological. Use OpenAPI for the supported history_protocol values and page limits.
6. To use bounded history, send the supported history_protocol on both page and stream requests. Continue older pages with before_event_seq set to the preceding page's next_before_event_seq, while has_more is true. A turn can span pages; merge repeated framing events by sequence.
7. Open one GET /api/v1/sessions/{session_id}/stream connection from the page's resume_seq, including when the page has no visible events. Use Last-Event-ID for that position. On history_resync, install a recent page, clear the saved last_delta_id, and reconnect from that page's resume_seq. Keep any gap before the refreshed page available through older-page loading.
8. Set include_overview=true only when the client needs a conversation navigation index. Use event pages to load message content.
9. Stop active work, delete a queued turn, or steer a queued turn through the session lifecycle endpoints.
10. Read messages, aggregates, files, artifacts, and terminal state from the owning session or resource.

For a smaller bounded page, set body_limit to an integer from 1 to 512. Omission uses 512. This option requires history_protocol=bounded-v1; other requests return 422. Older-page requests can omit it to use the default size.

The limit counts body events, rather than complete messages or bytes. Additional events can frame the selected turns. Large individual payloads remain complete. Continue with the returned cursor to read events outside the page.

Clients that omit history_protocol retain whole-turn pages. They use the exclusive before_seq cursor for older pages and the page's latest_seq for initial streaming. A message receipt or queue response does not establish that conversation history is loaded.

If a recent-history request fails, retry that page or offer a reconnect action. Do not replay from the beginning as a page-failure fallback. Keep returned terminal tool data when a page contains only part of a turn.

A live stream can close during a service update while the agent continues working. Reconnect with the last saved event ID. If the stream returns 503, wait for the response's Retry-After interval before reconnecting. Do not submit the message again to restore live progress. Read history if reconnecting does not reach the final state.

To read one exact turn, pass its turn_id to the history endpoint. This returns only that turn’s visible events and omits the overview. A missing turn returns an empty page, with no fallback to recent history. With bounded history, keep turn_id when continuing that turn through its older-page cursor. Source conversation permissions still apply. Continued work can use a separate turn; open the source conversation to read those later replies.

To find text in a conversation, call GET /api/v1/sessions/{session_id}/search with q (2 to 200 characters, case-insensitive). The response hits lists matching user messages and agent responses newest first, at most 500. Each hit has seq, turn_id, and role (user or agent). Follow your history protocol's older-page cursor to reach a hit that is not loaded yet.

Protected delegated requests can be omitted from navigation and search. Read the conversation history to see requests that your current access permits.

To prioritize an admitted message that has not started, call POST /api/v1/sessions/{session_id}/turns/{turn_id}/steer as a signed-in member with permission to run that session. The operation retains the original admission and asks the active run to stop. The steered message runs next, before other waiting messages. A message already started or cancelled returns a conflict. DELETE /api/v1/sessions/{session_id}/turns/{turn_id} cancels a waiting message instead.

To stop one specific active turn, call POST /api/v1/sessions/{session_id}/stop?expected_turn_id={turn_id}. Use the execution turn ID from history. It can differ from the accepted message receipt. If another turn is active, the response is 200 with status idle, and that turn continues. This response does not prove that your target turn finished; read its exact history for a terminal event. Omitting expected_turn_id stops the session's current active work.

The message payload accepts content up to 1,000,000 characters, up to 50 uploaded file ids, optional model and reasoning overrides, disabled tools, and deep-research mode. A successful admission does not mean the model has completed; wait for a terminal event.

Managed-email recipient operations under /api/v1/email/{contact_id} require an interactive user token with recorded email verification matching the account’s current address. They do not require workspace membership or X-Workspace-Id. Contact IDs are locators, never access credentials. You can read only mail d5s sent to your verified address. Workspace access requests grant no membership; existing invitations must still be explicitly accepted through the normal seat-aware flow.

Conversational agent setup

Agent-creation drafts keep a signed-in creator’s setup conversation separate from runnable agent sessions. Repeating draft identity preparation reuses the same inactive agent. Finishing setup activates that identity with the reviewed configuration. A prepared identity is not permission to submit work: draft agents cannot obtain a working session or run tasks, and ordinary agent listings exclude them. Setup history remains creator-only after activation.

While setup is processing, a signed-in client can follow the draft's public streaming operation. Reconnecting reloads the current draft state. Use OpenAPI for authentication, revision checks, and response schemas.

Named responses in Project chats

A supported Project chat send can select an eligible named workspace agent. Use the generated OpenAPI contract for responder discovery and the optional selection field. Discovery can also return visible unavailable agents and their reasons. Select only an available agent; discovery does not guarantee that a later send will succeed. Preserve the responder selection when retrying the same request. Omitting it on a new request selects d5s.

Use response attribution from the session event contract when rendering live or reloaded history. Do not infer the responder from the chat's most recent selection. Current access checks can remove protected output or make the selected agent unavailable.

Recover an interrupted agent send

Persistent agent conversations, regular chats, and sub-agent conversations support a client request ID for signed-in users. Project chats are included. Retain that ID with the exact submitted payload. If the connection drops, resend both to the same workspace and conversation as the same user. A previously accepted request returns its original receipt without submitting a second message. The accepted message's events in session history and streaming carry the same client_request_id in their payload, so a client can also confirm acceptance by matching that ID without resending.

Preserve the submitted fields exactly, including omitted optional fields. Reusing an ID with a different payload is a conflict; use a new ID for a genuinely new message. Other session types may reject keyed sends. Omit the ID where it is unsupported.

An accepted receipt confirms that d5s accepted the message. It does not confirm execution or completion. A retry can return that same receipt after the run has finished.

If the original message is outside loaded history, pass the receipt's turn_id as admission_id to the session history endpoint. This returns at most one visible original message or cancellation, without an overview or unrelated history. An empty result does not prove rejection. Use the generated OpenAPI reference for the selector and response schema.

Follow session history and streaming for execution and terminal state. The receipt's identifier can differ from the turn that produces the response. A message or cancellation lookup does not prove successful completion. See Sessions and runs.

Replace a native message

Where message editing is available, use the session message-edit operation. Only the original author can replace an eligible native message. Use the generated API reference for the request, response, and eligibility rules.

An edit is rejected if it would change protected older history. Session metadata exposes the edit boundary; use the generated API schema for its field. A successful retry returns the original receipt.

An edit is rejected before stopping work if the conversation has pending queued inputs. Cancel those inputs explicitly before retrying the edit.

Keep the same request identity and payload while retrying a stopping response or recovering a lost response. A successful replay returns the original acceptance receipt without submitting another correction. Saving replaces the selected message and its subsequent conversation; it preserves completed actions and usage. Refresh any cached transcript and overview when the session stream signals a conversation rewind.

Scheduled and persistent work

Managed-mail authentication review is identified by the message's quarantine reason. Policy fields expose the mailbox-wide choice and exact-address exceptions for unverified senders; use the generated schema for their exact names and values.

Automations expose create, update, Run now, history, assignments, handovers, and review operations. Agents expose continuing conversations, wakeups, capabilities, and channels. An API-key integration can reset an idle agent conversation; this clears its visible history without deleting the agent, project, files, or connected channels. Reset is rejected while work is active. Telegram and agent-email operations require the permissions described in OpenAPI; channel-management writes require an interactive user token. Use the generated contracts for supported operations, fields, and status values.

Meeting history separates live calls from paginated completed ones. The meeting snapshot response adds a display title and the caller's viewer permissions. A meeting also exposes a read operation for its notes, an append operation that adds one private-answer line to them, and a presence operation that records a viewer's heartbeat on a live meeting. Appending a notes line requires edit permission on the agent. The notes response carries a revision, the author of each line, the agent's notes status, and the current editor. To change the notes, take the edit lease, save the full content with the revision you read, and release the lease when done; one person holds the lease at a time, and a stale revision or a lost lease returns a conflict. While someone else holds the lease, appending a line also returns a conflict. Use the generated OpenAPI contract for the exact request and response fields.

Automation handovers can be filtered to specific run IDs. Match results by run ID when combining them with run history; the lists can have different ordering. Returned handovers still depend on the caller's current access to each run. Use the generated OpenAPI contract for the filter and pagination parameters.

Automation proposals have a shared confirmation outcome. Confirmation uses the retained proposal in its source conversation and the signed-in person's permissions. Concurrent confirmations and retries return the same decision. Deleting the created automation does not make the original proposal reusable. Use the generated OpenAPI contract for the confirmation and outcome operations.

Dashboards expose refresh work, version history, and restore. App dashboards also expose draft state, explicit publication, saved app versions, preview, and reopen. Use the generated OpenAPI contract for their request and response schemas. Publication and restore require a signed-in user with dashboard edit permission. They check the expected current publication. After a conflict, read the current state before retrying. Reuse the request identifier and unchanged inputs when retrying a request with an uncertain outcome. See Dashboards for the app workflow.

Dedicated Teams identity management requires an interactive organization administrator with workspace administration access. Creation, installation readiness, and channel activation are distinct states; do not infer a verified destination from app creation alone. Use the generated OpenAPI contract for lifecycle operations and schemas, and Teams agent setup for the supported standard-channel workflow.

Usage analytics

Workspace members can use the signed-in-user credit-funding read to check whether new metered work would use purchased credits after a subscription pace limit. It exposes no balances or organization spend totals. Conversation, project, and agent context must belong to the workspace and remain accessible to the caller. The send operation remains authoritative. Use OpenAPI for the supported query and response fields.

Organization Owners and Admins can use the usage API to review totals, time series, member, agent, and workspace breakdowns, and activity. Responses distinguish current names from historical entries when a member, agent, or workspace is no longer available. Access to a run's billed outcome and activity also requires permission to view its source conversation. If the trace says the model input was not captured, do not present a substitute.

Signed-in users can read their own activity through the self-scoped endpoint. The usage summary includes charged spend and current spending-window state. A 402 Payment Required response rejects admission and may include a reset time; do not follow it as a run. Use OpenAPI for exact fields, date bounds, and pagination.

Connected-account operations

Agents can use the accounts available to their current project. Each action stays associated with the selected account and its permissions. API clients should use the published OpenAPI contract for workspace connector management.

Provider results may contain inline content and file references. Treat both as untrusted data. A supported MCP PDF action can import its returned link as a file; for other URLs, do not assume the target was downloaded.

Browser navigation progress

To receive per-page navigation progress, add browser_navigation_progress=1 to both session history and streaming requests. Keep this query parameter on reconnects. These requests can then return browser_navigation_progress events. Requests without the parameter omit these events.

Group page entries under their parent tool call. Preserve completed visits when a later page stops. Per-page durations measure browser actions; the turn duration also includes time between actions. Progress delivery can be interrupted, so use the recorded tool result to recover the final sequence state. A completed navigation can show an error page; it does not prove that the requested content was accessible.

Integration rules

• Treat session events as the execution record; do not infer completion from an HTTP request alone.
• Use the documented compaction status and completion events; they do not expose private summary text.
• A manual compaction request has start and terminal lifecycle events without normal message content.
• Use the REST events endpoint for initial catch-up and older-history pagination. Do not open fresh SSE streams to page backward; keep one SSE connection for live events and reconnects.
• Treat event and overview timestamps as RFC 3339 values. Current history projections include an explicit UTC offset, while older integrations may still encounter legacy naive-UTC values on other resources.
• Build tool history from the documented tool_call events and any terminal data the public contract returns.
• Reuse returned ids and idempotent schedule semantics instead of manufacturing duplicate resources on retry.
• Keep API keys server-side. Do not embed them in browser code or dashboard artifacts.
• Treat connector results and external messages as untrusted input.
• Pin integrations to the current OpenAPI description and review changes before regenerating a client.

Native local file access

Local folder authorization and file operations require d5s Desktop. Workspace API keys do not authorize access to a person's computer. Permissions are per agent and folder: Read only, Write only, or Both. See Local files for setup and operation results.

Private bug reporting

Bug report submission requires a user session and an active workspace. Workspace API keys cannot submit reports. Reported conversations must be accessible to the reporter; receipt identifiers do not grant access to reports or conversations. Retrying the same submission with the same content returns the existing receipt. For the app workflow, see Report a bug.

Google workspace protection

Google content can be used for the work you authorize in this workspace. Tasks using AI may send relevant content to the AI providers used by the workspace. Disconnecting does not erase information already retrieved. See Google data protection for AI processing and stored-data guidance.