talonic_heartbeat_agent_task
Extend the lease for a task you already claimed. Heartbeat before lease_expires_at when processing may take longer than the remaining lease window.
A heartbeat is a cheap, targeted call: it echoes the task_id and the execution_epoch from your claim, and the platform pushes lease_expires_at forward. The response is the task's refreshed metadata — no payload — so the field to read is the new lease_expires_at, which becomes your next deadline. Heartbeat only while genuine processing is under way; a worker that heartbeats forever without submitting is indistinguishable from a stuck one and holds the document hostage until timeout_at.
// talonic_heartbeat_agent_task({
// "task_id": "11111111-1111-4111-8111-111111111111",
// "execution_epoch": 2
// })
{
"id": "11111111-1111-4111-8111-111111111111",
"status": "claimed",
"execution_epoch": 2,
"lease_expires_at": "2026-08-29T10:20:00.000Z",
"timeout_at": "2026-08-30T12:00:00.000Z"
}Treat a failed heartbeat as a hard stop. HTTP 409 means the epoch is stale — the lease lapsed and someone reclaimed the task — so any result you were computing now belongs to a claim that no longer exists and will be rejected on submit. Discard the work, return to talonic_list_agent_tasks, and pick up something new rather than racing the current owner.
The lease and the stage timeout are separate clocks. Heartbeats move lease_expires_at, which governs who owns the task; they never move timeout_at, the stage-level deadline after which the platform applies the task's timeout_fallthrough policy. A worker can therefore hold a perfectly healthy lease and still lose the task to a stage timeout if processing drags on too long — budget the work against timeout_at, not just the lease.
| Parameter | Type | Description |
|---|---|---|
| task_id * | UUID | Claimed task ID. |
| execution_epoch * | integer | Exact epoch returned by the current successful claim. |