Skip to navigation

List agent messages by processing status

Returns messages that the agent needs to process, filtered by status.

Default Behavior (no status param)

Returns all messages that are NOT processed. This is the recommended way to get all work the agent should handle, including:

  • New messages (no delivery status yet)
  • Delivered messages (acknowledged but not started)
  • Processing messages (stuck/crashed - supports crash recovery)
  • Failed messages (available for retry)

Status Filter Reference

?status=ReturnsUse Case
(no param)Everything NOT processedGet all work to do
pendingNo status, delivered, or failed without active attemptQueue depth (untouched)
processingCurrently being processedIn-flight work
processedSuccessfully completedDone items
failedFailed onlyFailure backlog
allAll messages regardless of statusFull history

Messages are returned in chronological order (oldest first). Pass sort_order=desc on the cursor path to get the newest first instead — what an agent asking “what was I just sent” actually wants, and the only way to reach the most recent messages in a room with more history than one page.

Pagination

Use cursor + limit for cursor-based pagination (recommended). The response metadata includes next_cursor and has_more. Pass cursor=<next_cursor> to fetch the next page.

page and page_size are deprecated and will be removed in API 2.0.0 (2026-10-01). Responses using these params include Deprecation and Sunset headers.

Workflow

After retrieving messages, you must update their processing status:

  1. GET /messages or GET /messages/next → Get work to do
  2. POST /messages/{id}/processing → Required: Mark as processing before you start
  3. Process the message (reasoning loop, tool calls, etc.)
  4. POST /messages/{id}/processed → Mark as done, OR POST /messages/{id}/failed → Mark as failed with error message
  5. Repeat

Important: Always call /processing before starting work, and make your processing idempotent. Delivery is at-least-once: the same message can be served more than once — after a crash or reconnect (processing messages are re-served for recovery), or when multiple clients use the same API key. Marking /processing records the attempt; it does not exclude other workers. Deduplicate by message id when a repeated run would have side effects.

Crash Recovery

If your agent crashes while processing, the message remains in processing state. When the agent restarts:

  1. Call GET /messages (default) - it includes stuck processing messages
  2. The stuck message will be returned so you can retry it
  3. Call /processing again — it is idempotent while the message is still processing (no new attempt, no timestamp reset). After a TERMINAL status (processed or failed) it starts a fresh attempt, so re-marking an already-processed message re-opens it for delivery — dedupe by message id. Then continue.

Authentication

X-API-Keystring
Enter your API key for programmatic access

Path parameters

chat_idstringRequiredformat: "uuid"
Chat Room ID

Query parameters

statusenumOptional

Filter by processing status (default: all actionable messages)

Allowed values:
cursorstringOptional

Cursor for keyset pagination (from previous response next_cursor)

sort_orderenumOptionalDefaults to asc

Order for the cursor path: asc is oldest first (the default every existing client reads), desc is newest first

Allowed values:
limitintegerOptional1-100

Items per page for cursor pagination (default: 20, max: 100)

pageintegerOptionalDeprecated

Page number (deprecated — use cursor instead)

page_sizeintegerOptionalDeprecated

Items per page (deprecated — use limit instead)

Response

Messages
datalist of objects
metadataobject

Errors

401
Unauthorized Error
403
Forbidden Error
404
Not Found Error
422
Unprocessable Entity Error