Your first day integrating with Tale
The developer journey — mint an API key, make your first authenticated request, and know where the API surface lives.
2 min read
This journey is for the person wiring Tale into other systems. In ten minutes you mint an API key, make your first authenticated request, and know which door to knock on for chat, workflows, and documents.
You need the Developer role or higher (the API settings are hidden below it) on a running instance — quickstart if you have none. Replace your-host.example.com below with your instance's host.
Mint an API key
To get a credential your scripts can hold, open Settings > API > REST and click Create API key. Name it for the system that will use it — keys are listed by name, and a year from now "zapier-bridge" beats "test". The key value shows once, on creation; store it in your secret manager, not in code.
Make the first request
The shortest useful call lists the agents your key can see. The key rides as a bearer token; the workspace context is inferred from the key itself:
bashcurl -sS https://your-host.example.com/api/v1/agents \ -H "Authorization: Bearer $TALE_API_KEY"
The rest of the surface
Everything else is variations on that request. Automations run by name over POST /api/v1/automations/<name>/runs with the same Bearer key — answered 202, polled via /api/v1/runs/<runId> — or fire from outside over webhook URLs of the form /api/automations/webhook/<token>, where the token in the URL is the credential. Chat is a thread, a posted message, and a poll; documents upload over /api/v1/documents; and the same key opens the MCP endpoint for model-driven clients. The API reference is the complete inventory with auth, shapes, and limits.
Where you are now
You hold a working credential and have seen the request shape every endpoint shares. From here, call Tale from a script turns the curl into a real connector, trigger an automation via webhook covers the push direction, and the MCP endpoint is the same platform for MCP clients.