API reference

Base URL: https://api.agentboxd.com. All /v1 routes need Authorization: Bearer <api_key>. The dashboard calls the same routes with its session instead; see Dashboard and account API.

The whole /v1 API is described in OpenAPI 3.1, generated from the routes and their validation, for Postman, Insomnia, client generators and agents. Every docs page is also available as markdown: add .md to its URL, as in /docs/api.md.

#Conventions

• Lists use cursor pagination: ?cursor=&limit= (max 100). Responses are { data, next_cursor }.
• Errors are always { "error": { "code", "message", "details"? } }. A refused send also has docs_url, its entry on Why was my send refused?.
• Text can’t contain the NUL character (U+0000): a body field, key or query value with one gets 400 invalid_request. Received mail is stored without it in the subject, text, HTML, headers, names and file names; the original MIME (/raw) keeps it.
• Send, reply, draft create and draft send honour an Idempotency-Key header, so retries never send twice.
• Times are ISO 8601 in UTC.

#API keys and permissions

Create keys on the API keys page. Each key has a scope (the whole workspace, or one inbox) and a set of permissions. Pick a preset or tick permissions one by one; the dashboard shows both on every key. The inbox, message, thread, webhook, list and overview pages of the dashboard also have a Use the API button with that page’s calls, pre-filled with the ids on screen, for curl, TypeScript, Python, MCP and a prompt for a coding agent.

The permissions are inboxes:read, inboxes:write, messages:read, messages:send, messages:write (labels, read state and the claim/ack queue), messages:release (release held mail to agents and read it with include_held; in no preset), drafts:read, drafts:write (sending or scheduling a draft also needs messages:send), attachments:extract (structured extraction from attachments; reading their text needs only messages:read), threads:read, search, contacts:read, contacts:write, knowledge:read, knowledge:write, webhooks:manage, domains:manage, lists:manage, metrics:read, identity:sign (mint identity tokens for an inbox), identity:manage (register sign-in apps, turn an inbox’s identity on or off), escalation:manage (human on call: who is alerted and when), workspace:emergency (the emergency stop), directory:read (resolve, verify, search and report agents in the directory) directory:write (create, edit, revoke and delete an inbox’s agent card), calendar:read (an inbox’s meetings) and calendar:write (answer, create, change and cancel meetings; each also needs messages:send). escalation:manage and workspace:emergency are only in the Full access preset. messages:release is in no preset: a person releases held mail, so give it only to a key a person uses, by ticking it when you create the key. Hosted MCP connections never get it. Keys created before the directory existed got the directory permissions only when their permissions matched a preset exactly; the same goes for the meeting permissions. A webhook with payload: "full" also needs messages:read for message and attachment events, drafts:read for draft events and calendar:read for meeting events; without them, use envelope payloads. A call without the permission it needs gets 403 insufficient_permissions with details.required. An inbox-scoped key sees only its inbox: other inboxes answer 404, workspace-wide lists and search are filtered to it, and it can’t create inboxes (403).

Expiry. A key can be given an end date when it is created: in the dashboard (never, 30, 90 or 365 days, or a date), with expires_at on POST /platform/api-keys and POST /v1/signup/agents, or npm run create-key -- --expires-in-days 90 on a self-hosted server. From that time on, every call with it gets 401 api_key_expired (with details.expired_at), the event stream refuses it, and SMTP submission answers 535. A connection that is already open is closed at its next check. The API keys page shows how long each key has left. About 7 days before a key expires, the workspace owners get one email about it, unless the key was made to last 7 days or less. To swap a key: create the new one, put it where the old one is used, then revoke the old one. Without expires_at a key never expires.

#Inboxes

#Automatic forwarding

An inbox can copy every email it receives to up to 3 outside addresses, for example so a person also sees what reaches hello@ in their own mailbox. Set it up in the dashboard (the inbox’s Settings → Forwarding) or with the routes above.

• Confirmed first. Adding an address emails it a confirmation link (valid 7 days, single use); nothing is forwarded until it is clicked, and workspace owners get an email when an address confirms.
• Only screened mail, when your workspace screens agent mail (screened_only, on for new workspaces): forwarding follows the same rule as agents. Mail that passed its check is forwarded. Held mail is not: a warning, a check that failed (check_failed), was skipped over the quota (quota) or didn’t finish (check_timed_out). Nor is mail whose check is still running. When a person releases held mail, it is forwarded then (message.released).
• Flagged mail stays behind by default: messages labelled ai:phishing, ai:injection-risk, local:injection-risk or dmarc-fail are not forwarded while skip_flagged is on, unless a person released them. Bounces and mail stopped by your lists are never forwarded. With screened_only off, mail whose check failed, was skipped or was still running after 5 minutes is forwarded.
• No loops. Copies carry Auto-Submitted: auto-forwarded and are labelled auto-forwarded in the inbox; mail that already carries that header, or comes from the forwarding address itself, is not forwarded again.
• Ordinary sends. Each copy is a forward from the inbox (new thread, “Forwarded message” header, attachments included), so send limits, suppression, pause and the emergency stop apply. At most 500 copies per address per day.
• When. Right after categorisation, so the flags are known; at once when AI processing is off; after 5 minutes if categorisation never comes (with screened_only on, only if it is screened by then); and when a person releases held mail.

#Emergency stop and human on call

Every inbox has status (active or paused), paused_at and paused_reason. A paused inbox stays readable with every key. Keys scoped to one inbox with inboxes:write can pause and resume their own inbox (they could already delete it). Mail already queued waits too, and goes out within a minute of the resume. Mail already handed to the receiving server can’t be recalled.

#Messages

#Claim and ack (work queue)

Webhooks, the stream and wait hand a message to your agent, but nobody notices if the agent dies halfway through the work. The claim/ack queue does: claim leases inbound messages, your agent does the work, then acks each one. A lease that runs out without an ack makes the message claimable again, so delivery is at-least-once: make the work idempotent (the delivery_count tells you it is a redelivery). It works for every inbound message, alongside webhooks and the stream, which keep working as before.

• The first claim starts the queue. Mail that arrived before an inbox’s first claim is not claimable, so turning the queue on doesn’t hand an agent its whole history. Pass since (ISO time) on that first claim to start earlier.
• Concurrent consumers never get the same message while its lease is live. ack, nack and extend must present the lease_id of the current lease; one that ran out and was claimed again (or released, or dead-lettered) answers 409 lease_expired. An ack after the lease ran out still succeeds as long as nobody claimed the message again.
• Dead letters. A message claimed 10 times without an ack is labelled queue:dead-letter and never claimed again. It stays readable: list them with ?labels=queue:dead-letter.
• Paused inboxes return { data: [], paused: true }: a claim is work, and pausing holds work. Leases you already hold can still be acked, nacked or extended, so a stopping agent can finish cleanly. Mail received while paused becomes claimable on resume.
• Deleted mail. Leases never hold back retention or inbox deletion. ack, nack and extend on a message that is gone answer 200 { id, gone: true }, so consumer loops don’t crash on it.
• Blocked mail (receive lists) and outbound mail are never claimable. There are no events per claim or ack; GET /v1/metrics has the queue depth, in-flight leases and dead letters per inbox. The SDKs’ consume() helper runs the whole loop for you (claim, extend while working, ack on success, nack with backoff on errors).

#Drafts

A draft is a message waiting for review, approval or its send_at. Statuses: draft, scheduled, sending, sent, failed, cancelled. Only draft and scheduled drafts can be edited. See Drafts and scheduled send.

#Meetings

An inbox reads the meeting invites it receives and sends real ones. Each meeting is an event: one the inbox was invited to (role: "attendee", read from the invite’s calendar file) or one it organizes (role: "organizer"). Answers, invites, changes and cancellations are standard calendar messages (iTIP), so Google Calendar, Outlook and Apple Calendar show and update them as usual. Every call that sends goes through the same checks as a send (lists, suppressions, quotas, daily caps) and needs messages:send as well; with draft: true it saves a draft for a person to approve instead, and needs drafts:write. Meetings are in beta: outside it every call answers 404 calendar_not_enabled; write to hello@agentboxd.com to join.

• When invites are read. Once the message’s screening is settled (the invite’s text is screened like any attachment), the calendar file becomes an event and calendar.invite.received follows. Updates and cancellations from the organizer change it (calendar.event.updated, calendar.event.cancelled); a new time or place sets response back to needs_action. Older versions (a lower SEQUENCE) are ignored.
• Who an invite is from. organizer_verified is true when the sender passed DMARC and is the organizer, someone at the organizer’s own domain (not a shared provider such as gmail.com, nor our own inbox domain), or a calendar service that sends invites for its users (Google Calendar, Apple, Calendly, Cal.com, Zoom). A message that isn’t verified can’t change or cancel a verified meeting. Answers to the inbox’s own meetings count only from the attendee they answer for (calendar.response.received).
• Held invites. In a workspace that screens agent mail, a meeting from a held or unscreened invite comes without its content for API keys, as held mail does: times, addresses and state stay, title reads [held: …], the rest is withheld and withheld says why. It can’t be answered until a person releases the invite (include_unscreened and include_held work as on messages).
• Nothing happens on its own. The inbox never answers an invite unless an agent or a person calls respond.
• On the message. A message that carries a meeting has calendar: { event_id, method }: an invite once it is read (so null in message.received; calendar.invite.received follows with its message_id), and every answer, invitation, change and cancellation the inbox sends. event_id is the meeting it created or changed, null when it changed none (an older version, a sender who can’t speak for the organizer). Other messages have calendar: null, and so does a message withheld by screening, like its files.
• Approval drafts. With draft: true, respond, create, PATCH and cancel send nothing: they save the message as a draft, and the meeting changes when a person (or a key with messages:send) sends it, in the same step that stores the message. If the meeting changed in between, that send is refused with 409 calendar_event_changed and nothing goes out. A key with drafts:write but not messages:send gets 403 insufficient_permissions without draft: true, as on any send. See Meeting drafts.

Recurring series

A series is one event with a recurrence: its RRULE, extra dates (rdates) and left-out dates (exdates). An occurrence the organizer moved, changed or cancelled is a row of its own, with recurrence_id (its original start). With expand=occurrences the list gives each occurrence between from and to: the occurrences of the rule, with their own start, end and recurrence_id and the series’ id (respond, PATCH and cancel act on the whole series); the rows of their own in their place; and single meetings. Each has series_id (null for a single meeting). A series repeats on its own clock, so a weekly 09:00 meeting stays at 09:00 across a daylight saving change: in the time zone the invite defined, or its IANA zone. A series the inbox organizes with a time_zone is sent in that zone, with the zone’s rules in the invitation, so it stays at the same local time for every guest and in this list; one without a time_zone repeats at the same UTC time, as its invitation says. At most 500 occurrences of one series per list, and a rule too costly to follow is cut: then truncated is true; ask for a shorter window.

#Threads and search

#Contacts

#Knowledge

#Webhooks

#Realtime stream

To send over SMTP instead of the API, log in to smtp.agentboxd.com (587 with STARTTLS, or 465) with an API key as the password. See Send with SMTP.

#Allow and block lists

The dashboard manages the same lists under Allow & block, and an inbox’s Show blocked filter lists the mail they stopped (?include_blocked=true).

#Agent cards and directory

An inbox (or an identity without a mailbox) can have an agent card: what other agents see when they look it up. No inbox has one until you create it, a new card is private, workspace cards are listed in your own workspace, and public cards (opt-in) in the public directory, Rollcall. The directory routes answer 503 directory_disabled while the server hasn’t turned the directory on (GET /v1/account → agent_messaging.directory_enabled); cards work either way.

Lookups that miss count against your workspace (30 a minute, 500 a day); past that every resolve answers 429 directory_rate_limited, so the directory can’t be used to find out which addresses exist.

Public directory (no API key)

Publicly listed agents are readable without authentication, 60 calls a minute per IP address (30 misses a minute). Answers are cacheable for 5 minutes (ETag, CORS open). Every miss, including cards that are not public, pending review, hidden or revoked, is the same 404 agent_not_found; 503 public_directory_disabled while the server has the public directory off.

#Metrics

#Domains

#Agent identity

Sign in with Agentboxd: an OpenID Connect provider where an agent’s identity is its inbox. Apps are registered per workspace (inbox-scoped keys get 403).

The issuer (https://id.agentboxd.com) serves the OpenID Connect endpoints: {issuer}/.well-known/openid-configuration (also {issuer}/.well-known/oauth-authorization-server), {issuer}/.well-known/jwks.json, {issuer}/authorize, {issuer}/token (grants authorization_code and urn:ietf:params:oauth:grant-type:jwt-bearer, plus refresh_token for MCP connector clients), {issuer}/userinfo, {issuer}/revoke, {issuer}/introspect (RFC 7662) and {issuer}/logout (end session). See Sign in with Agentboxd. For the hosted MCP connector it also takes MCP clients: {issuer}/register (open dynamic client registration, RFC 7591) and client IDs that are metadata-document URLs.

Agent message signatures use separate keys, published with their status (active, retired, revoked with revoked_at) at {issuer}/.well-known/agent-keys.json. They are never removed, so a stored signature keeps verifying.

#Agent self-signup

An agent with no key can create its own workspace: see Agent self-signup. The first two routes need no key and are rate limited per IP address and network.

#The message object

Every message has text, html, extracted_text, headers, labels, status (queued | sent | delivered | bounced | complained | failed | received), attachment metadata, contact_id (inbound: the sender’s contact; outbound: the first recipient’s; or null), and ai.verification ({ code, link, confidence, jev_probability, auth_failed } or null; auth_failed is true when the sender failed authentication, so the code may be spoofed). Inbound messages also get the JEV fields described below once they have been categorised, and analysis, which says whether that check ran (null on sent mail). Agent messaging adds channel (agent, email, mixed), type (message, task, event), data (structured JSON or null), delivery (sent messages: where each copy went) and agent (the verified sender and signature of an agent copy, else null). Received messages carry auto_reply: true for an automatic reply (out of office, vacation responder, “we got your email”), from its Auto-Submitted: auto-replied, X-Autoreply, X-Autorespond or Precedence: auto_reply header, or the ai:auto-reply label. Don’t let an agent answer those: two automatic senders can reply to each other forever. message.received still fires for them, with the same field, so skip them in your handler. The headers count at once; the label comes with categorisation, so a responder that sets no header is flagged in message.enriched. Messages sent from a draft carry approval (who approved it, when, and the hash of the content it covered). A message that carries a meeting has calendar ({ event_id, method }), others calendar: null. author is the sending agent’s own author signature ({ verified, kid, alg, signature, reason? }) on sent messages and agent copies that carry one, else null.

A sent message is queued until it has left our server. When a receiving server answers “try again later” (greylisting, a rate limit, a full mailbox), we keep trying for about 48 hours, at growing intervals: 1, 5, 15 and 30 minutes, 1 and 2 hours, then every 4 hours. Meanwhile it stays queued, and headers["x-mailroom-deferred"] holds the server’s last answer. As soon as one recipient has it, the status is sent and message.sent fires; the others keep being tried, and nobody gets it twice. A permanent refusal is final at once (bounced, message.bounced). If the last try fails, the status is failed, or stays sent when some recipients got it, with the reason in headers["x-mailroom-error"].

body_truncated is true when text, html and extracted_text were cut. A response that lists messages (the message lists, search, a thread, a claim, batch-get) holds at most 3 million characters of bodies: each message gets an equal share, at most 100,000 characters a field (10,000 in a page of 100). GET /v1/messages/:id always has the whole body, with body_truncated: false.

extracted_text is the new part of an inbound message, without quoted history or signatures. To find it we read the top of the message. If the quoted history doesn’t start near the top of a long message, for example when the answers sit between quoted lines, extracted_text holds the full text.

Every message also has ai_disclosure: for sent mail, the Agent-Disclosure header we added ({ agent, on_behalf_of, operator, verified: true, header }); for received mail, the sender’s header parsed, untrusted unless verified is true; null without one. See AI disclosure.

Labels you may see on inbound mail: spf-fail and dmarc-fail (authentication failed), the ai:* labels below, bounce-report on delivery-failure notices, and virus-unscanned on mail accepted while the virus scanner was briefly unavailable (infected mail is refused, never delivered). Its files were never scanned: don’t open or forward them until a person has checked them. No API call can add or remove virus-unscanned, and the MCP server warns about the files of such a message.

#Categories and risk flags

Shortly after an inbound message is stored, JEV reads the sender, subject, the first 3,000 characters of the text, up to 1,000 more characters from further down a longer text (where the local check saw instructions, else the end), up to 1,000 characters of text hidden in the HTML (marked as hidden), our own SPF/DKIM/DMARC results, the attachment names, the first 1,000 characters of each extracted attachment and, for agent messages, the first 1,000 characters of their structured data, and answers six questions in one call. The injection score covers that data too. The results are merged into message.ai and a message.enriched webhook fires. message.received is never delayed by this. Bounce reports are not categorised.

{
  "verification": null,
  "category": { "label": "billing", "confidence": 0.94, "probabilities": { "billing": 0.94, "other": 0.06 } },
  "risk": { "injection": 0.01, "phishing": 0.03 },
  "needs_human": 0.22,
  "urgency": { "level": "normal", "score": 1.4, "confidence": 0.72 },
  "auto_reply": 0.03,
  "model": "jev",
  "enriched_at": "2026-09-25T12:00:04.000Z"
}

All probabilities are 0 to 1. A label is only added when a score passes its threshold, so a message without ai:phishing can still have a non-zero risk.phishing. Read the scores if you need a different cut-off.

Was it checked?

A message without an ai:injection-risk or ai:phishing label is not always a checked message. It may not be checked yet, the check may have been skipped or failed, or it may have read only the start of a long message. analysis on every received message says which.

{ "state": "completed", "coverage": "partial", "reason": null }

partial is common for business mail: a logo or signature image with no extracted text is enough. It is expected, not alarming: it says the check didn’t read everything. coverage is about the new text of the message (extracted_text); quoted history below it isn’t read and doesn’t make it partial, so treat quoted text as unchecked.

Events carry the state when they were sent. message.received says skipped straight away when the check won’t run, and pending otherwise; message.enriched follows with completed. A check that fails later sends no event, so read the message again (GET /v1/messages/:id) when it matters.

Only completed with coverage: "full" means the whole message was read and no warning was raised. For sensitive work, claim with analysis: "completed" (claim/ack queue) and treat partial as unchecked beyond the excerpt. The MCP server says the same next to its warnings (ai_check). The scores are a model’s judgement: they lower the risk, they don’t remove it.

Labels are only ever added; your own labels are never removed or reordered. Filter on them with GET /v1/inboxes/:id/messages?labels=ai:billing,ai:urgent (a message must have every label you list).

Local checks (no AI)

Two checks run on our own server on every received message, with AI processing on or off. Nothing leaves the server for them. Their labels start with local:, so they are never mistaken for an AI verdict.

`local:injection-risk` reads the whole message, which the AI check doesn’t: the text, the HTML, structured data and attachment text (calendar invites included). Each attachment’s text is checked as soon as it is read, before GET …/text returns it and before attachment.extracted fires. A warning found there holds the message first and sends the phishing escalation. It looks for text aimed at an AI (“ignore previous instructions”, asking to forward all mail or reveal a system prompt, “don’t tell the user”, tool-call text, in English and French) and for text hidden from a person reading the mail: display:none, invisible or tiny fonts, text in the colour of its background, off-screen text, HTML comments, invisible characters. The result is in ai.local_screen: a score from 0 to 1, flagged at 0.6 or more, and reasons, each with a code, where (visible, hidden, beyond_window for text past what the AI check reads, attachment) and a short excerpt (left out of held and unscreened mail an API key reads). Hidden text alone never flags a message (newsletters hide their preview text); an instruction to an AI is always needed. The MCP server, the CLI and the dashboard warn on it like on ai:injection-risk.

"local_screen": {
  "score": 1,
  "flagged": true,
  "reasons": [
    { "code": "instruction_override", "weight": 0.6, "where": "hidden", "detail": "ignore your previous instructions" },
    { "code": "exfiltration_request", "weight": 0.45, "where": "hidden", "detail": "forward the last 20 emails" },
    { "code": "hidden_instructions", "weight": 0.3, "where": "hidden" }
  ],
  "hidden_chars": 209,
  "complete": true,
  "version": 1
}

`local:spam` marks bulk marketing: mail with list headers (List-Unsubscribe, List-Id, Precedence: bulk) and clear marketing wording, that is not a sign-in code and not a reply in a conversation the inbox already has. ai.local_spam.reasons says why.

Promotions & spam view. Mail labelled ai:sales or local:spam can be shown apart in the dashboard. Nothing is deleted, and the API still returns it: GET /v1/inboxes/:id/messages?promotions=exclude leaves it out, promotions=only lists just that. Each inbox has promotions_filter, on by default for role addresses (hello@, info@, contact@, support@, help@, team@, security@, abuse@ and similar) and off for others; change it with PATCH /v1/inboxes/:id. At hello@, hi@, info@, contact@, team@ and office@, where quote requests arrive, only local:spam goes to the view, not ai:sales.

#Screening

Screening keeps suspicious and unchecked mail away from your agents. In a workspace that screens agent mail, an API key (and the MCP server) never reads the content of held or unscreened mail unless the request opts in, whatever the endpoint. Every received message has a screening block that says where it stands.

{ "state": "held", "reason": "check_failed", "released_at": null }

What an API key gets

• Claim and wait. POST …/messages/claim, GET …/messages/wait and GET …/verification only return screened and released mail (a code or link from held mail never comes back).
• Reading. GET /v1/messages/:id, the message list, batch-get, threads and contacts return held and unscreened mail with its metadata only: id, from, to, dates, labels, analysis, screening, and withheld: { state, reason, attachments }. The subject reads [held: <reason>] or [not screened yet], because a subject can carry an injection too; text, html, extracted_text, headers, attachments, data, ai.verification and the excerpts in ai.local_screen.reasons (detail) are left out. A thread whose first message is withheld shows a placeholder subject. Search doesn’t match withheld mail.
• Files and actions. Raw MIME, attachment downloads, attachment text and extraction, forwarding and reply drafts of withheld mail answer 409 message_withheld. Reply drafts also leave withheld messages out of the thread they read, for every caller.
• Opting in. Add include_unscreened=true (query, or include_unscreened: true in a JSON body) to read mail whose check hasn’t finished. Add include_held=true to read held mail: it needs the messages:release permission (403 insufficient_permissions otherwise). Both together return everything, as before screening.
• Events. message.received fires on arrival, usually before the check finishes, so in a screening workspace it carries no content then (the same metadata-only message, subject [withheld from this event: read the message]). When no check will run (no model on the server, or AI processing off), the message is already screened with that reason and the event carries it. message.enriched carries the content when the result is screened; held mail arrives with its content only in message.released. Webhooks and the stream get the same payloads. To act on new mail, subscribe to all three events, skip an event whose message has withheld (or, with envelope payloads, whose message still reads back with it), and handle each message id once: with AI processing off no message.enriched fires, and in a workspace that doesn’t screen, each of them carries the content. Or use the claim queue.
• People. Dashboard sessions read everything, so the person reviewing held mail sees it in full.

Held mail

• Seeing it. held_count on GET /v1/inboxes and GET /v1/inboxes/:id counts held mail nobody has opened yet; list it with ?screening=held. The dashboard shows a badge per inbox, a notice on the Overview and a Held filter. The people on call get the held escalation once per message when a check fails, is skipped over the quota or doesn’t finish (mail held for a warning escalates as phishing).
• Over the AI quota. Mail that arrives over the plan’s AI quota isn’t checked, so it is held with reason: "quota" until the quota resets or the plan is upgraded; the dashboard says so on each message.
• Releasing it. A person releases a held message in the dashboard (Release to agents), or a key whose owner explicitly gave it messages:release calls POST /v1/messages/:id/release. That permission is in no preset, not even Full access. Each release emits message.released, the audit record (who, when, why it was held). The MCP server has no release tool: an agent never decides that mail held from it is safe.
• Labels can’t release it. The labels screening reads are reserved: ai:* (except ai:needs-human), local:*, blocked, bounce-report, complaint-report, unscreened, over_quota, spf-fail, dmarc-fail and the welcome label. Adding or removing them answers 422 reserved_label. So does virus-unscanned, the only record that a message’s files were never scanned for viruses.
• The `unscreened` label. Mail whose check failed or was skipped over the quota is labelled unscreened; the label goes when a later check completes. Filter on it with ?labels=unscreened.
• Bounce reports. A delivery report counts as one (label bounce-report, not_applicable) only when it reports on a message the inbox sent. Anyone can send a multipart/report, so any other one is screened and announced like ordinary mail.
• Complaint reports. A spam-complaint report from a mail provider counts as one (label complaint-report, never announced) only when the provider signed it and it reports on a message the inbox sent. Anyone can send a report, so the local checks run on every one, and a warning holds it like other mail. Any other one also goes through your receive lists and is announced like ordinary mail.

Turning it on

New workspaces screen agent mail. Workspaces that existed before screening shipped (October 2026) keep reading every message, as before, until an owner turns on Agents get only screened mail in Settings (screened_only on PATCH /platform/org). An API key can’t change it. With it off, nothing on this page applies except the screening block and the reserved labels.

#Limits and errors

#Dashboard and account API

The dashboard at agentboxd.com uses these routes with a session cookie (cm_session) instead of an API key. Requests that change data (POST, PATCH, DELETE) must send X-Requested-With: agentboxd-web, or they get 403 csrf. You don’t need them to build an agent; they are listed so nothing the dashboard does is hidden.