Complete API
Send messages, trigger tasks, read journals, download Drive files, and manage employee configurations. Authentication uses API keys with scoped permissions. Full documentation with request and response examples.
Programmatic access to your workforce.
Build on your AI workforce with a full REST API, client SDKs, and webhooks in both directions. Expose any employee as an MCP server for Claude, Cursor, and Windsurf, or as an A2A agent for cross-platform agent collaboration. Everything the UI can do, the API can do.
The workspace is one way to interact with your AI employees. The API is another. It gives you programmatic access to every capability.
Expose any employee as an MCP server or A2A agent and external tools and agents can use your workforce directly.
SDKs make integration fast. Webhooks push events to your systems in real time.
The entry point is deliberately small. Send a POST to the chat endpoint with an employee's ID and a prompt, and that employee's reply comes back as JSON. There is no stripped down text model hiding behind it: the request runs through exactly the same pipeline as the chat window, with the same skills, the same connected tools, and the same memory of your business. Anything you would type into the workspace, you can send from your own code and get the same quality of answer.
Calls are synchronous, so your code waits for the result instead of polling for it. Real work takes real time, so a request holds the connection while the employee thinks and uses its tools, for up to five minutes. When you would rather fire and forget, post the event to the inbound webhook endpoint instead: you get an acknowledgement straight away and the employee picks the work up in the background. That is the right shape for a failed deploy, a new order, or a support ticket that should just be handled.
Authentication is one Bearer API key that you generate in your workspace settings, and the same key covers every programmatic route: the REST API, the MCP endpoint, A2A, inbound webhooks, and email. Each of those channels is switched off until you turn it on, so a new workspace exposes nothing to the outside world by accident. Turn a channel back off and the route stops answering immediately, which makes revoking access a single toggle rather than a migration.
Exposing an employee is the half most people underestimate. Turn on the MCP endpoint and your coding tools can talk to a trained employee by ID, including Claude Desktop, Claude Code, Cursor, Windsurf, and anything else that speaks the Model Context Protocol, after one config block and a key. Turn on A2A and any client speaking the open agent-to-agent protocol can discover what your employees handle, hand one a task, and collect the result. Traffic runs the other way too, since an employee can call an outbound webhook, your own service, or a Zapier or Make scenario as a tool during a task. Official client libraries for JavaScript and Python are on the roadmap and are not published yet, so today you call the REST API directly, which is the same integration point those libraries will wrap.
Send messages, trigger tasks, read journals, download Drive files, and manage employee configurations. Authentication uses API keys with scoped permissions. Full documentation with request and response examples.
Any AI employee can be exposed as an MCP server for Claude, Cursor, and Windsurf, or as an A2A agent for cross-platform collaboration. Your workforce becomes callable infrastructure.
Inbound webhooks let external systems push work to your agents. Outbound webhooks notify your systems when tasks complete, approvals are needed, or schedules fire. Closed-loop automation.
Build on top of your AI workforce with a full REST API, webhooks, and SDKs, or expose your agents as callable services.
The Sista Developer API gives you programmatic control over every part of your AI workforce. Hire agents, assign tasks, read activity, trigger actions, and retrieve results through a consistent REST API. Inbound webhooks let external systems push events to your agents. Outbound webhooks let your agents notify the rest of your stack when work is done.
You can also expose any AI agent as an MCP server or as an A2A agent, making it callable by other AI systems, tools, and orchestrators. Your AI employee becomes a service. Other agents, your coding tools, or your own orchestration layer can delegate work to it directly. Client libraries for JavaScript and Python are on the way; today the integration point is the REST API itself, which is a plain HTTP call with a Bearer header.
Nothing is reachable until you say so. Every programmatic channel starts switched off and is enabled per employee from the channel settings, and one Bearer API key covers all of them, so you are not managing a different credential per protocol. Because each route runs the same employee, the answer your backend receives is the answer your team would have seen in chat, with the same training, the same connected accounts, and the same memory behind it. Switch a channel off and it stops accepting requests straight away.
Use the REST API to assign tasks, retrieve results, and manage employees programmatically. Integrate AI workforce capabilities into your own product without touching the UI. One POST with the employee's ID and your prompt returns their answer as JSON, run through the same pipeline as the chat window.
Subscribe to events: task completed, approval requested, message sent. Your systems receive a POST the moment something happens and can act on it immediately. In the other direction, your systems can post an event to the inbound endpoint and get an acknowledgement instantly while the employee works in the background.
Other agents and tools can call your AI employee as an MCP tool. Drop them into any MCP-compatible workflow and they participate as a first-class tool. Claude Desktop, Claude Code, Cursor, and Windsurf all connect with one config block and an API key, and the employee answers with its own training and tools.
Publish your AI employee as an A2A agent so external agents can delegate tasks to them. Works across platforms, orgs, and tech stacks using an open protocol. The calling agent discovers what your employees handle before it sends anything, so you are not writing glue code to describe them.
Yes. Every AI employee is reachable over a REST API: send a POST to the chat endpoint with that employee's ID and your prompt, and the reply comes back as JSON. The request runs through the same pipeline as the chat window, so the employee still has its skills, connected tools, and memory of your business. You generate a Bearer API key in your workspace settings and switch the channel on before it accepts anything.
No. Most people never touch the API, because employees connect to apps like Gmail, Slack, and your CRM through ordinary in app connections, and you can hand an employee a webhook URL from Zapier or Make without writing a line of code. The API exists for when you want your own product or backend to drive an employee directly. Both routes reach exactly the same employee.
Authentication is a Bearer API key you generate inside your workspace, and the same key covers the REST API, the MCP endpoint, A2A, and inbound webhooks. Every programmatic channel starts switched off, so a brand new workspace exposes nothing to the outside. Turning a channel off again closes the route immediately, which makes revoking access a single toggle.
Yes. Switching on the MCP endpoint publishes your employees to any Model Context Protocol client, including Claude Desktop, Claude Code, Cursor, and Windsurf. You paste one config block containing your API key, then send prompts to a specific employee by ID from inside that tool. What answers is your trained employee with its own skills, tools, and memory, not a blank assistant.
A REST call is synchronous and holds the connection while the employee does the actual work, for up to five minutes. That suits any request where you want the answer inline. When the job is long or you do not need a reply at all, post to the inbound webhook endpoint instead: it acknowledges immediately and the employee continues in the background.
Yes. Give an employee an outbound webhook, whether that is your own endpoint, a Zapier or Make scenario, or a Slack incoming webhook, and it becomes a tool the employee can call during a task. It sends a JSON payload the moment the work is done, so the rest of your stack finds out without anyone checking manually. Because that moves data outside Sistava, each send waits for your approval by default.
Client libraries for JavaScript and Python are on the roadmap and are not published yet, so today you call the REST API directly. That is a normal HTTP request with a Bearer header and a JSON body, which most languages handle in a handful of lines. When the libraries land they will wrap the very endpoints you would be calling now, so nothing you build today gets thrown away.
A2A is an open agent-to-agent protocol that lets another AI agent discover your employees, understand what each one handles, and hand it a task without custom glue code. Reach for the REST API when your own code is in charge and already knows which employee it wants. Reach for A2A when the caller is itself an agent that needs to find the right worker and agree on the shape of the task first.
When you expose an AI agent as an MCP server or A2A agent, it becomes a reusable service in your stack. Other systems can call it, delegate to it, and receive structured results back. This makes your AI workforce composable: build once, use everywhere.
The REST API and SDKs let any engineering team integrate Sista into existing products and workflows. You are not locked into a GUI. Every action available in the UI is available via API, so you can automate the automation layer itself.
We exposed our Sista agent as an MCP server and connected it to our internal AI orchestrator. It now receives tasks from three different systems without any manual routing.