GET /v1/send-status/:commandId

GET /v1/send-status/{commandId}

Apple Delivered and Read are GET /v1/send-status/:commandId, a live read on the Mac. They are not SSE events and they do not change command status.

Ask after a message.send has settled succeeded (outbound echo proved). A Delivered stamp on Apple's side does not emit a second event: command.

This is a synchronous read. The answer is in the HTTP response. Nothing is stored; a later call asks the Mac again. null timestamps mean unknown, not "not delivered" or "not read" — a recipient with read receipts off leaves readAt null forever.

Request

curl https://api.mapier.ai/v1/send-status/cmd-1 \
  -H "Authorization: Bearer $MAPIER_API_KEY"

commandId is the id the 202 handed you.

Response

200 — Delivered, not Read

{
  "commandId": "cmd-1",
  "deliveredAt": "2026-08-24T18:03:14.000Z",
  "readAt": null
}

Prop

Type

Documented misses:

Status	Meaning
`200`	The Mac answered. Timestamps may both be null.
`404`	Unknown `commandId`, not yours, or no outbound echo GUID to ask about.
`503`	The Mac cannot read right now (offline, capability, or a read in flight).

What this is not

Not an SSE event. The stream will not tell you the message was Delivered.
Not a change to status. succeeded stays succeeded.
Not GET /v1/messages/{id}/receipts. That path is not this read.

For message.send, succeeded means the Mac ingested our outbound echo — the bubble exists in chat.db. It is not Apple's Delivered stamp and it is not the moment iMessage first returned a GUID (accepted, not streamed).

Command settlement events

succeeded is echo-proved. Then pull this.

GET /v1/response_stream

No Apple receipts on SSE.