Skip to main content
An API trigger runs an agent on demand when an authenticated HTTP request is made to the workspace session endpoint. Unlike event and schedule triggers, an API trigger doesn’t fire on its own — your code calls it.
In the CLI and REST API, API triggers are referred to as api triggers.

Create an API trigger

1

Open your workspace

Go to guild.ai and open the workspace where the agent is installed.
2

Go to Triggers

In the left sidebar, open More and click Triggers, then click New trigger.
3

Choose API

Select API and choose the agent this trigger will run.
4

Copy the credentials

Once the trigger is created, copy the combined credentials string (<api_key_id>:<api_key_secret>) displayed in the dialog. This string is shown only once — store it securely.

Trigger API keys

Every API trigger is authenticated by a trigger API key: a combined <api_key_id>:<api_key_secret> credential generated when you create the trigger. Each key is scoped to that one trigger. You can give a key an optional name to identify its purpose or origin — for example, ci-pipeline. Names are up to 100 characters and shown alongside the trigger in the web UI.
Creating and managing trigger API keys is currently exclusive to the web UI. There is no CLI subcommand for managing keys, and no endpoint for it on the public API — use the Triggers page in your workspace.

Trigger a session

Guild uses HTTP Basic Authentication to authorize API requests. Your API key is the credential pair: the key ID is the username and the key secret is the password. Pass the combined string as the authentication parameter (for example, with curl -u "<api_key_id>:<api_key_secret>").
Make programmatic calls to the public API host, https://api.guild.ai. It accepts API key authentication only — browser session cookies and task tokens are rejected.
To start a new agent session, make a POST request to the workspace’s sessions endpoint:

Request body

The request body must be a JSON object with:
  • session_type: Must be set to "api_trigger".
  • agent_input: A JSON object matching the input schema of your agent.
  • agent_id (optional): Route the session to a different agent installed in the workspace, given as owner~agent-name or as a UUID. Omit it to run the trigger’s configured agent.

Example

Response

Returns 201 with the created session. session_type is always "api" for sessions started by an API trigger, regardless of the "api_trigger" value you sent in the request.

Interactive follow-up

If the agent is conversational or awaits subsequent inputs, you can post follow-up events directly to the session:

Request body

  • mode: Set to "text" (default) or "json".
  • content: The message content. For "text" mode, a string; for "json" mode, a JSON object.
Requests authenticated with a trigger API key only deliver text to the agent. If you send multiple text parts they are joined with spaces, but there is no way to attach an image or file — that’s only supported for messages sent by a logged-in user through the chat UI.

Example

Response

Returns 201 with the created event. Events posted with a trigger API key are recorded as trigger_message events.

Retrieve session status

Retrieve the current execution state and metadata of a specific session:

Example

Response

Returns 200 with the same session shape as Trigger a session. root_task.status and token_usage update as the agent runs:
root_task.status is one of CREATED, DISPATCHED, STARTED, WAITING, DONE, ERROR, or INTERRUPTED. DONE, ERROR, and INTERRUPTED are terminal — poll until you see one of those to know the agent has finished.

Fetch session events (logs and thoughts)

Retrieve the chronological feed of logs, agent thought progress, LLM usage statistics, tool calls, and final outputs:

Query parameters (Optional)

  • limit: Maximum number of events to return (default: 20, max: 1000).
  • offset: Number of events to skip (default: 0).
  • from_id: Only return events with an id greater than this one — use the last event id you’ve seen as a cursor to page forward without offset.
  • types: Comma-separated list of event types to filter by (e.g., agent_console, trigger_message,user_message).
  • sort_by: Sort order (default: -id, newest first).

Example

Response

Returns 200 with a page of events, newest first by default. Every event has id, entity_type, created_at, updated_at, task, and type; the remaining fields depend on type.
Container log events
The response can include container_log events, carrying standard output and standard error produced inside a task’s container.

Fetch session sub-tasks

Fetch a list of all sub-tasks spawned by parent agents or tool calls inside this session:

Example

Response

Returns 200 with a page of tasks, oldest first. The root task (the one your trigger started) has parent_task_id: null; tool calls and sub-agent runs appear as their own tasks with parent_task_id pointing back to the task that spawned them.

Real-time streaming (WebSockets)

If you are building a real-time interface or monitoring tool, connect to the session events WebSocket instead of polling GET /v1/sessions/{session_id}/events.
Authenticate with the same API key, sent as an Authorization: Basic header on the connection request.
The header is the only way to authenticate this connection. A browser’s built-in WebSocket cannot set request headers, so connect from a server-side or native client instead.

Security and scope

  • Workspace Scope: The API key carries workspace-level permissions. This allows it to read and write (including fetching status, event feeds, sub-tasks, and runtime statuses, as well as sending follow-up events/messages) to any session in the same workspace.
  • Execution Identity: Sessions started via an API key do not run on behalf of a human user (acting_user_id is None). However, when viewing the session’s chat feed in the UI, any events generated by the API will display the avatar of the user who originally created the trigger.
See Manage triggers for activating, deactivating, listing, and inspecting triggers of any type.