REST API endpoint
POST /v1/inbox/tasks/{taskId} — close, dismiss or snooze a task
Closes a task the agent raised. Only rows whose type is task can be resolved here, and done means the thing was actually handled.
Karl-Gustav Kallasmaa, Founder & CEOLast updated The request
Paste this and change the key. Every endpoint takes a bearer key and none takes a workspace id — the key names the workspace.
curl -X POST https://api.attensira.com/v1/inbox/tasks/tsk_4f2a \
-H "Authorization: Bearer $ATTENSIRA_API_KEY" \
-H "Content-Type: application/json" \
-d '{"state": "done"}'
Parameters
Every parameter the published reference documents, and nothing it does not.
| Name | In | Type | Default | Notes |
|---|---|---|---|---|
| taskId* | path | string | — | From the inbox listing, and only for a row whose type is task. |
| state* | body | enum | — | done, dismissed or snoozed. |
| snoozed_until | body | string | — | An RFC 3339 timestamp. Required when the state is snoozed, and refused otherwise. |
The response (200)
Abbreviated, never invented — this is the shape the published reference documents.
{ "id": "tsk_4f2a", "state": "done" }
What goes wrong, and what it means
The condition on the left, the correct reading of it on the right.
- The id belongs to an ask or a work item
- Those are not resolvable here. An ask is answered inside the session it names; a work item is approved or declined in the dashboard.
- snoozed_until sent with a state other than snoozed
- It is refused rather than ignored, which is the safer behaviour — a silently dropped deadline would look like a snooze that never came back.
- The task reappears with a higher occurrence count
- Marking it done did not fix the underlying problem. The agent hit the same wall again, and the count is the evidence that the resolution was administrative rather than real.
What this endpoint cannot tell you
The limits are part of the answer, not a disclaimer under it.
- Marking a task done queues nothing. It records that the thing the agent needed has been handled — it does not retry the work, and an integration that expects a resolution to restart a run will wait indefinitely.
- It cannot approve work. Approvals are a different row type with a different mechanism, so an integration built on this endpoint can clear blockers but never authorise anything the agent proposes to do.
The inbox lists what is waiting on a person. This is the one endpoint that takes a row off it — and only one of the three kinds of row, which is the first thing to get right.
Only tasks
A task is something the agent raised because it hit a wall: an integration it does not have, a permission it was refused, a decision it cannot make. Those close here.
The other two kinds do not. An ask is a run parked on an approval, and it is answered inside the session it belongs to, where the context of the question is. A work item is a proposal, approved or declined in the dashboard. Sending either of their ids to this endpoint is asking for a control that does not exist on this surface, and the design reason is worth stating: closing an approval by API would let a script authorise work without anybody reading what the work was.
Three states, and they mean different things
done is a claim about the world. It says the thing the agent needed has actually been handled — the integration is connected, the access is granted, the decision is made. It is not a promise to handle it later.
dismissed says you have looked and decided not to act. That is a legitimate and frequently correct answer, and recording it as dismissal rather than as completion keeps the history honest.
snoozed says the problem is real but not now, and it requires a timestamp saying when it should come back. Sending that timestamp with any other state is refused rather than quietly ignored, which is the right call: a dropped deadline would present as a snooze that never returned.
Nothing is queued
This is the single most important behavioural fact about the endpoint, and the one that catches integrations out. Resolving a task does not retry anything. No run is scheduled, no work restarts, nothing is re-attempted on the spot.
What actually happens is simpler and slower: the obstacle is recorded as cleared, and the next time the agent runs into that part of the job, the wall is gone. If you have just connected the thing it was asking for and you want work to happen now rather than on the next schedule, that is a separate call — running an automation, or asking the agent directly.
Honesty as an operational habit
Because the count of occurrences on an inbox row keeps rising while a problem persists, a task marked done that reappears with a higher count is a legible signal. It means the resolution was administrative: somebody cleared the row without clearing the cause.
That feedback loop only works if done is used for its actual meaning. A team that closes rows to keep the list tidy converts the most useful diagnostic in the product into noise within a fortnight, and the count is the thing that tells you so.
Its twin on the other surface
The resolve_inbox_task MCP tool takes the same id, the same three states and the same snooze timestamp, and needs the write scope. It is a good tool to expose to an assistant, because clearing a blocker is usually a sentence — "I've connected GitHub, close that one" — and the assistant already has the row in front of it from the inbox listing.
Snoozing well
Of the three states, snoozing is the one most often used badly. A snooze with no thought behind the date simply moves a row a week into the future and produces the same conversation again. A useful snooze is set to the moment something changes — the day access is expected, the day after a release, the start of a quarter — so that when the row comes back there is a reason to expect a different outcome. The timestamp is required precisely because a snooze without one would be a dismissal with extra steps.
Questions people ask
- Does marking a task done make the agent retry?
- No. Nothing is queued when you send it. It records that the thing the agent needed has actually been handled, so the next scheduled run finds the obstacle gone.
- What is the difference between done and dismissed?
- Done says the problem was fixed. Dismissed says you have decided not to act on it. Both close the row, and the distinction is the honest record of which happened.
- When should I snooze instead?
- When the problem is real but not now. Snoozing requires an RFC 3339 timestamp, and sending one without the snoozed state is refused rather than ignored.
- Can I resolve an approval this way?
- No. Only rows whose type is task. An approval is answered in its own session, and a proposal is approved in the dashboard.
- What scope does this need?
- The write scope. It changes workspace state, even though it spends no credits.
Sources
Every factual statement above, with the page it came from and the date that page was read.
The Attensira API reference states that done means the thing the agent needed has actually been handled, not that you intend to handle it, and that nothing is queued to run when you send it.
docs.attensira.com · retrieved
“done means the thing the agent needed has actually been handled, not that you intend to handle it — nothing is queued to run when you send it.”
The API reference states that only rows whose type is task can be resolved through this endpoint, and that an approval is answered in its own session.
docs.attensira.com · retrieved
“Only rows whose type is task can be resolved here. An approval is answered in its own session.”