MailSchema
Search/Read MAP
The protocol at work

From email to service.

The email describes the decision. A connection you approved reads the current proposal from the service and submits your choice through the interface the service already provides.

Review one send.

Read the current campaign, then approve or decline. Try changing the audience or permission after review to see what happens when the service checks again.

Example inbox Interactive illustration
Example campaign serviceTo owner@example.net

Send product update

The product update is ready to send to the newsletter audience. Please review the email and approve this send.

Requested by
Campaign editor
Audience
4,210 newsletter subscribers
Timing
When approved
Inbox actionsservice.example

Read the current campaign through your connected account.

Inspect the exchange

The simulated service checks again when you decide. These cases run locally.

Local service model · TypeScript
Review the request, then choose an action to inspect the local call.

The service owns its request and result format. Inspect the worked HTTP and MCP exchanges →

Read the email's MAP description
{
  "@context": "https://mailschema.org/contexts/map-0.3.jsonld",
  "@type": "MailAction",
  "profile": "https://mailschema.org/profiles/map/0.3",
  "type": {
    "id": "https://mailschema.org/types/campaign-send-approval",
    "version": "0.1",
    "contractDigest": "sha-256:de3c88a0712adb1d0c6e82f437b825c83520d8e1c44c7b032a2cfcfe5ce55731"
  },
  "@id": "urn:uuid:0199a6c2-4b1e-7c3a-9d2e-5f8a1b2c3d40",
  "issuedAt": "2026-10-02T08:00:00Z",
  "expiresAt": "2026-10-03T08:00:00Z",
  "inLanguage": "en",
  "service": {
    "id": "https://service.example",
    "tenant": "urn:example:tenant:7"
  },
  "recipient": "owner@example.net",
  "subject": {
    "id": "urn:example:campaign:18",
    "title": "Send product update"
  },
  "terms": {
    "id": "urn:example:proposal:c18",
    "version": "c18-r2"
  },
  "human": {
    "url": "https://service.example/review/c18"
  },
  "details": {
    "summary": "The product update is ready to send to the newsletter audience. Please review the email and approve this send.",
    "requester": "Campaign editor",
    "content": {
      "id": "urn:example:content:18",
      "revision": "r2",
      "digest": "sha-256:86d8e5d2331a2c3bd211a71adb79149b644104ccbb7a4425b7ac5b26e94ef06d",
      "title": "Product update"
    },
    "sender": {
      "mailbox": "news@service.example",
      "name": "Service newsletter"
    },
    "audience": {
      "id": "urn:example:audience:9",
      "revision": "snapshot-3",
      "count": 4210,
      "label": "Newsletter subscribers"
    },
    "schedule": {
      "mode": "immediate"
    }
  },
  "operations": [
    {
      "id": "approve"
    },
    {
      "id": "decline"
    },
    {
      "id": "request-changes"
    }
  ]
}
JSON contract Campaign content
Simulated inbox and service. No email is sent.How this type works
In the email

Publish this revision.

A proposal, its exact terms and the decisions you can make.

Type contractPublication ApprovalApprove · Decline · Request changes
At the hostTrusted binding

Read the current proposal. Check policy. Obtain confirmation when required.

What a binding establishes
At the serviceResearched interface families

APIs & RPC

Call an existing operation

Agents & tools

Use a connected service

Messaging

Deliver a decision

Channels & federation

Carry calls, progress and results

The service checks permission and exact terms when it records the decision.

MAP can use existing service descriptions, account access and discovery. The interfaces shown here have been researched, not implemented as MAP integrations.

Explore the full research

Different paths. The same decision.

A service may expose an HTTP operation, a tool or another authenticated interface. In every case, it must know who is acting, which proposal they saw and whether they are still allowed to make that choice.

Read the full sourced assessment →

Reuse what the service already has.

Keep the service's existing operations, authentication and result format. An installed binding identifies which operation matches the type. A description cannot make an unsafe operation safe: the service must check permission and the proposal version when it acts.

How to document a binding →
Worked exchanges

Inspect one publication decision.

These HTTP and MCP illustrations use the same proposal, service read and exact revision. They show the steps in code. The wider research catalogue records the requirements for other interfaces.

Publication Approval · worked exchanges

Your API. Its existing operation.

After the host checks the content and obtains approval, the mapping sends the decision and exact version through the service’s own request format.

HTTP · decideReview
POST /reviews/p7/decision HTTP/1.1
Host: service.example
Content-Type: application/json

{
  "decision": "approve",
  "expected_revision": "p7-r4"
}

The service checks permission and expected_revision together. Changed terms stop publication.

Read the OpenAPI description
These exchanges illustrate the same service decision.See the wider interface research

About the artifacts

The description, content, native API example and MCP exchange are generated from one set of source artifacts. Changing the contract regenerates their identity and digest together. The OpenAPI document describes the illustrative service, with no custom MAP mapping language.

What they establish

These exchanges explain the design; they make no live service calls or interoperability claim. The MIME download is unsigned. MCP initialization and account setup are omitted. Actual implementations need evidence for the service's authorization, version check and result interpretation.