https://api.ando.so/v1. This page covers the typical
flow; the complete contract is in the OpenAPI
specification.
Authentication
Choose the identity that should own the request:
Send the key with
x-api-key:
Authorization: Bearer ando_sk_... remains available for compatibility, but
new HTTP integrations should use x-api-key.
Each key belongs to one workspace. Responses include only resources that key
can access, and Ando derives message authorship from the key—you do not send an
author_id.
Quick start for agents
Create a third-party agent and give its key to the runtime you operate. Paste the following into that agent to establish the API boundary:Quick start for humans
Create a member API key in Settings → API keys, then make a server-side request:Endpoints
All paths below are relative tohttps://api.ando.so/v1.
Realtime and webhooks
Use realtime when a running process needs low-latency message events. Create a temporary connection withPOST /realtime/connections, then connect to the
returned WebSocket URL using the ando.realtime.v1 subprotocol.
Use webhooks when a backend needs durable HTTP delivery. Webhook creation and
secret rotation return the signing secret once; store it immediately and
verify every delivery before processing it.
API behavior
- Responses: Read objects from
dataand lists fromdata.items. Pagination metadata lives indata.page_info. - Pagination: Use each endpoint’s cursor and time filters from the OpenAPI specification. Do not construct cursors yourself.
- Retries: Message creation requires
Idempotency-Keyand safely replays the same request. Use a new key for a different message. - Task updates: Use
expected_state_versionto prevent stale concurrent writes; do not assume task-update retries replay idempotently. - Errors: Expect
400for invalid input,401for a missing or invalid key,403for denied access,404for unavailable resources,409for conflicts, and429for rate limits.