JMAP for mail

JMAP defines a general synchronization protocol over HTTP and JSON. RFC 8621 applies it to email objects, mailboxes, searches, changes, and submission.

It can batch several method calls into one request, use state tokens for incremental synchronization, and receive push updates instead of polling constantly.

JMAP is not SMTP with JSON syntax. It is an application protocol that can replace much of an IMAP-style client interface while existing mail servers still use SMTP for Internet transfer.

A JMAP client first discovers the session object. It learns the API URL, accounts, capabilities, upload URL, and download URL instead of guessing endpoints.

Method calls can be chained in one request:

{
  "using": ["urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail"],
  "methodCalls": [
    ["Email/query", { "accountId": "a1", "filter": { "isUnread": true } }, "q1"],
    ["Email/get", { "accountId": "a1", "#ids": { "resultOf": "q1", "name": "Email/query", "path": "/ids" } }, "g1"]
  ]
}

The second call uses IDs produced by the first. Batching reduces round trips while keeping each method result explicit.

State strings support incremental synchronization. If the client presents stale state to a change method, it must follow the defined recovery path rather than overwriting newer server data.

JMAP runs over HTTPS, so normal HTTP authentication, TLS validation, status handling, and request-size limits still matter. The JSON body can contain method-level errors even when the HTTP request itself succeeded.

Identify the query call, result reference, and get call above. Add the state value your local cache would need for a later incremental sync.