Docs

Recipes

1. A support agent with a connector

Describe the agent with the connector it needs named explicitly — e.g. "a support agent that can look up open tickets in our Notion database and answer questions about them." The builder grants the notion connector automatically if you mention it; otherwise add it from the agent's Tools tab. Configure the connector's credentials once under Settings → Connectors — instructions and a sample value are shown for whichever connector you pick.

2. A multi-step research workflow

For anything beyond one call-and-respond — loop until a quality bar is met, branch based on what a step actually returned — open the agent's Graph tab. Add an agent node for each LLM step, a tool node for anything that calls out, and a router node to decide what happens next from the real output, not a fixed order. Every step shares one state object and the whole run is traced as a single unit, the same as a simple agent.

3. Calling an agent from your own backend

Generate a platform API key under Settings → API keys, then POST to the agent's chat endpoint:

curl -s https://api.yan-tra.com/provision/agents/{agent_id}/chat \
  -H "Authorization: Bearer yk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"text": "What'\''s the status of order #4821?"}'

The agent needs the rest channel bound before an API-key caller can reach it — add it from the agent's Channels tab if it isn't already there.

API reference

Authentication

Every request needs Authorization: Bearer yk_live_.... A platform API key is either tenant-wide (usable against any of your deployed agents with the rest channel bound) or scoped to one specific agent at creation time. Keys are shown once, at creation — only a hash is stored server-side, so there's no way to retrieve a lost key; revoke it and create a new one.

Base URL

https://api.yan-tra.com

Send a message to an agent

POST /provision/agents/{agent_id}/chat

{
  "text": "your message"
}

→ 200 OK
{
  "trigger_id": "trig_...",
  "status": "done",
  "response": "...",
  "error": null,
  "ai_generated": true,
  "disclosure_shown": false
}

Errors

• 401 — missing or invalid API key.
• 402 — a plan limit was reached (monthly call allowance or, on the pooled runtime, the platform budget cap). The response names which one.
• 403 — the agent doesn't have the channel this call needs bound.
• 404 — no agent with that id, or a scoped key trying to reach a different agent than it's scoped to.

Rate limits

There's no separate per-second rate limit today beyond your plan's monthly call allowance (see pricing) — stated plainly rather than making one up.

Retention & audit

Every run — chat, scheduled, or API-triggered — is captured as a trace: the prompt, every tool call and its result, tokens used, cost, and latency, tied to one trigger_id. You can see it in the console under an agent's Traces tab.

How long a trace is kept is a plan setting, not a policy document — Free keeps 7 days, Pro and the trial 90, Team 13 months, Enterprise is configurable with legal-hold support. A scheduled job enforces this on both the metered usage record and the trace itself; a trace past its window is inaccessible via the console and the API alike, independent of whether the purge has physically run yet.

Where an agent's compliance profile requires it, EU AI Act Article 50 disclosure — telling the end user they're talking to an AI — is applied automatically and recorded per response, not left to the agent's own prompt.

A public, real example trace — the actual proof of all of this — is planned here but not live yet: publishing one safely needs a dedicated, narrowly-scoped read endpoint and a check that nothing sensitive ends up in it, rather than just turning on public access to trace data. Once that's built, it'll be linked from here.