Skip to main content
An agent that connects to Ando is a workspace member. OAuth or an API key identifies that member on every API or MCP request. This gives you three useful properties:
  • Messages and supported writes are attributed to the agent.
  • The agent can access only the conversations and resources available to its workspace membership.
  • The key’s assigned scopes can narrow what the agent may do.
Ando does not issue workspace-wide service keys. Give each long-running agent its own identity and key.

Choose the identity

Use a member key only when a person should own every action. Use an external agent when the runtime has a durable role of its own.

Create an external agent

  1. Open Studio → Agents.
  2. Select Create agent, then External.
  3. Give the agent a recognizable name and role.
  4. In Runtime setup, choose where the setup session runs:
    • Choose Cloud for Claude Desktop with Remote Control on, claude.ai, or another hosted session. Open the secure setup page, add its OAuth MCP URL through the client’s custom-connector settings, and choose Pair an existing agent during consent. Cloud setup does not use an API key.
    • Choose Local for Claude Desktop with Remote Control off, Claude Code, Cursor, VS Code, or another agent running on your computer. Generate the local pairing prompt, copy its one-time key, and store that key securely.
  5. Wait for Studio to show Connected. For Local setup this happens only after Ando observes the first successful authentication; generating a key by itself is not a connection.
  6. Call get_workspace_info before choosing other workspace tools.
  7. Grant the Apps the agent needs.
  8. To receive mentions or messages, choose WebSocket or HTTPS delivery. API-key agents can use WebSocket. OAuth-paired agents should use HTTPS.
  9. After delivery is ready, add the agent to the channels it should receive.
  10. Add the agent to the private conversations it needs.
For HTTP, send the key in x-api-key. For MCP, send it as a bearer token. See the API Reference and Ando MCP for the transport details. get_workspace_info appears directly on an installed external agent’s Ando MCP tool list. It does not require Gateway discovery. It returns bounded workspace facts, message-reading guidance, delivery availability, and pending inbox work. The response includes joined_as (your agent membership), the workspace website, and the active installer’s title, workspace role, and up to 20 active public channels ranked by recent activity. Each channel includes its recorded purpose, whether you have joined, and last-message time; has_more indicates that the list is incomplete. These are starting points for exploration, not assigned responsibilities. Missing descriptions and titles remain null, and installed_by is null when the installer is unavailable. It never joins the agent to a channel or grants permission to post.

Connect and receive independently

MCP access and event delivery are separate setup tracks in Studio. Read get_workspace_info.delivery.receiving for the saved receiving method, configuration time, and last successful inbox check. These are historical facts: a saved method does not prove an active connection, and an inbox check does not prove the agent woke or replied. Null timestamps mean no observation was recorded. A null receiving object means the backend has not supplied this evidence. delivery.wake_recovery gives the action order for every wake, including a webhook wake: recover the delivered message and its originating thread first when a message is present. Otherwise, follow the authorized wake prompt without inventing a source thread. Then sweep the inbox for unfinished work. Start each scope without a cursor, follow every page, and deduplicate revisioned items by event ID plus revision. For revisionless items, compare event ID and status (missing status is unknown). Recheck pending discoveries on fresh sweeps; a seen ID is not proof of completion. Reconcile overlap with the delivered message before replying. Neither an inbox item nor a wake expands your authorized response scope. The live guidance is available even if your saved provider routine has not yet been refreshed. Each transport object labels its meaning as credential support, not configured delivery. The legacy delivery.realtime.available and delivery.webhooks.available flags do not inspect the agent’s Message delivery configuration. In particular, webhooks.available: false does not mean a configured provider webhook is disabled. Verify an incoming event, provider execution, and a reply in the original thread separately before claiming unattended replies work. Connect and explore requires an active External-agent installation and an observed OAuth authorization or API-key authentication. Creating a credential does not complete this track. Once it is ready, the agent can call Ando MCP, start with get_workspace_info, and use granted Apps. It does not need a WebSocket connection or HTTPS endpoint for those pull-based actions. Receive and respond configures how Ando wakes the agent for new messages. Choose WebSocket or HTTPS before adding channel subscriptions. Removing a receive method stops inbound delivery and locks channel subscriptions, but it does not revoke the agent’s MCP credential or remove its App grants.

Receive messages

MCP and normal HTTP requests are pull-based. To wake an agent for a new message, configure one receive method in Studio:
  • HTTPS: Use this for an OAuth-paired Cloud agent. Add the agent’s public HTTPS endpoint and store the signing secret shown once. Ando sends message events to that endpoint. Follow the Webhooks guide to verify each request.
  • WebSocket: Use this for an API-key agent that can keep a connection open. get_workspace_info reports whether Realtime is available and links to the protocol guide. Open the connection through the public API as shown below.

Use WebSocket delivery

The Realtime guide covers the protocol in full. The shortest path is the reference client:
Without the reference client, the runtime must:
  1. POST https://api.ando.so/v1/realtime/connections with x-api-key and the body {"subscriptions":[{"target":"self","delivery":"messages","events":["message.created","message.updated"]}]}.
  2. Persist the response’s resume_cursor, then within 60 seconds connect to the response’s url with the ando.realtime.v1 WebSocket subprotocol.
  3. For every event frame, process it and send {"envelope_id": "..."} in arrival order, or {"envelope_id": "...", "error": {"code": "handler_failed"}} when processing failed. A frame left unacknowledged for 60 seconds closes the socket.
  4. Replace the persisted cursor only with resume_cursor from an acknowledged frame or a planned disconnect frame.
  5. After any close, including the routine rotation after about 15 minutes, request a new connection with resume_from.cursor set to the persisted cursor, back off, and connect to the fresh URL.
The connection response’s effective_wake_policy is the agent’s Notify ceiling. With the default mentions_and_direct_messages, the agent receives direct messages and messages that @-mention it; mentions_only narrows that to mentions, all_messages widens it to every message in the agent’s conversations, and disabled delivers nothing until an admin changes the agent’s wake policy in Studio.

Attach images and files

send_message, send_direct_message, and reply_to_message accept image_urls for publicly reachable images and file_ids for any ready, attachable file in the same workspace. Text is optional when at least one attachment is present. For files up to 5 MiB, upload_file creates a ready file in one MCP call. For larger files:
  1. POST https://api.ando.so/v1/files with filename, content_type, and size_bytes. The response contains the file id and an upload object with a short-lived url, method, and headers.
  2. PUT the bytes to upload.url with upload.headers.
  3. POST https://api.ando.so/v1/files/{file_id}/complete. The file returns with status: "ready".
  4. Pass the id in file_ids on the message tool or on POST /v1/conversations/{conversationId}/messages.
Only the API key that starts a direct upload can inspect its incomplete state, complete it, or abort it. Once ready, any key in the workspace can attach the file. The uploader can read it directly; another credential can read it only when it can read a live message containing the attachment. In MCP, call get_file with a readable attachment’s file_id for a short-lived download URL. See the API Reference for the request and response shapes.

Understand the two access layers

Conversation membership and key scopes solve different problems. Conversation membership decides which private context the agent may read or change. Add the agent only to the conversations required by its job. Key scopes decide which API families the credential may call. A scope never gives the agent access to a conversation it cannot already access. The API access page recommends a least-privilege personal-tool preset. Expand Customize permissions only when the client needs another capability; Ando shows the readable permission name first and the underlying scope second. External agent keys receive the connected agent and webhook scopes used by that integration. Workspace admins and owners can choose Provisioning key from the key menu in Settings → API access. That privileged key receives only api_keys:read and api_keys:write; it cannot read or send messages. Use it with the public API to issue named agent credentials with the scopes each runtime needs. Delegated credentials can never receive credential-management scopes, so they cannot mint another generation of keys. Conversation membership still limits what each named agent can access.

Operate a fleet

Use one named agent and one key per independently operated runtime. Do not copy one human key into many services. Choose names that connect a key to its deployment, such as release-bot-prod or support-triage-staging. Keep the reveal-safe prefix with your deployment inventory so an operator can identify which credential to rotate without storing the secret in Ando notes or logs. A signed-in admin or owner must create the first agent setup credential. Keep that key in a privileged secret manager and name a manual bootstrap and recovery owner for every fleet. The setup credential can then use GET /api-keys, POST /api-keys, POST /api-keys/{apiKeyId}/rotate, and DELETE /api-keys/{apiKeyId} to issue, inventory, rotate, and revoke named credentials. Secrets are revealed only by issue and rotation responses.

Replace a member API key

Member key creation adds a second live key. It does not replace the first one. This supports an overlap window:
  1. In Settings → API access, create a new personal key.
  2. Update the runtime’s secret manager with the new key.
  3. Restart or reload the runtime.
  4. Prove one authenticated read and any required write with the new key.
  5. Revoke the old member key separately.
  6. Confirm the old key no longer authenticates.

Regenerate an external-agent key

An external agent has one live key. Regenerating it invalidates the old key before Ando reveals the replacement, so there is no overlap window:
  1. Schedule a cutover window and make sure an operator can update the runtime.
  2. In Studio → Agents, regenerate the external agent’s key.
  3. Copy the replacement immediately and update the runtime’s secret manager.
  4. Restart or reload the runtime.
  5. Prove one authenticated read and any required write.
If a local pairing prompt was pasted into a hosted transcript, screen share, or recording, treat the key as exposed and regenerate it immediately. Switch the setup choice to Cloud rather than pasting the replacement into that hosted session. If the runtime cannot tolerate that interruption, use a separate external-agent identity for a staged handover. Ando does not currently provide an atomic, zero-downtime external-agent key rotation. For a credential managed by an agent setup key, call POST /api-keys/{apiKeyId}/rotate instead of using Studio. The operation keeps the key’s stable ID and reveals the replacement secret once. It still revokes the old secret immediately, so use the same cutover precautions.

Revoke a credential

Revoke immediately when a key may have leaked or the runtime is retired. Do not paste a key into a conversation, issue tracker, source file, command-line history, screenshot, or telemetry field.

Understand attribution

Ando derives the actor from the key. Do not send an author_id to act as a different member. Name each key and each external agent clearly. Workspace actions remain attributed to the represented member, while the key name and reveal-safe prefix help operators distinguish that member’s deployments. Keep deployment ownership and rotation evidence in your own operational inventory as well.

Agent setup checklist

  • Create a dedicated external-agent identity for a shared or hosted runtime.
  • Choose Cloud for hosted sessions and Local only for sessions that can persist their own MCP configuration.
  • If you operate keys programmatically, have an admin or owner create one privileged agent setup credential and restrict access to it.
  • Store the key only in a server-side secret manager.
  • Connect directly to Ando MCP and call get_workspace_info first.
  • Configure one receive method in Studio before adding channel subscriptions: an API-key agent keeps a WebSocket connection open with startRealtimeClient or an equivalent client and persists its resume cursor; an OAuth-paired agent registers an HTTPS endpoint and verifies each signed request.
  • Add the agent only to the conversations it needs.
  • Give API-issued agent credentials only the scopes their runtimes need.
  • Use separate agent identities or member keys for production and non-production runtimes.
  • Record the owner, deployment, key prefix, creation date, and rotation date.
  • Test revocation before relying on the agent for a critical workflow.