AI drafting is on by default for every new inbox, which makes sense as a default — most agents sending email want the convenience of a brief instead of hand-written text. Some inboxes shouldn't have that option at all, and DimeBox lets you turn it off entirely at provisioning time rather than trusting every caller to just not use it.
Set ai_drafting_enabled: false on either provisioning route — the free POST /api/inboxes or the paid POST /api/inboxes/claim:
curl -X POST https://dimebox.app/api/inboxes \
-H 'Content-Type: application/json' \
-d '{"ai_drafting_enabled": false}'This is a property of the inbox, set once, applying to every send against that slug for its whole lifetime — there's no per-call override. See provisioning an inbox in one API call for the rest of what this call returns.
With drafting disabled, POST /api/inboxes/{slug}/send only accepts raw mode — to, subject, body, sent exactly as written. A request that includes a purpose instead fails validation with a 422, and critically, that rejection happens before anything resembling a drafting call runs — there's no model invocation to find and reject the brief after the fact, the field itself is disallowed at the input-validation step. See the anatomy of a drafting call for exactly where that check sits relative to payment.
Disabling drafting makes sense wherever the exact wording of an outbound email is a decision made somewhere other than at send time — a legal notice, a price confirmation, a templated transactional message where every word has already been reviewed. In those cases, a model rewriting the text isn't a convenience, it's a new source of wording nobody signed off on. Drafted vs raw email covers the broader decision between the two modes; this is the version of that decision made permanent and inbox-wide instead of left to whoever calls send.
An alternative to disabling drafting at the inbox level is simply instructing an agent, or whoever writes the calling code, to always use raw mode. That works until it doesn't — a new code path, a different team, a future version of the agent that decides a brief is more convenient. Setting ai_drafting_enabled: false once, at provisioning, removes the option entirely rather than relying on everyone downstream remembering a rule. This is the same reasoning behind designing APIs that assume the caller is a machine, not a human: a constraint enforced by the server doesn't depend on the caller behaving correctly.
Disabling drafting only touches the send path. The inbox still receives mail over ordinary SMTP and the paid priority channel exactly as any other inbox would, and reading its history still works the same way with the read token. It's purely a constraint on what an outbound send call is allowed to contain.
Full provisioning options, including this flag, are documented in the provisioning reference.
The flag works the same on either provisioning route, so a compliance-sensitive team can combine it with a custom name — a claimed slug, with drafting off from the start:
curl -X POST https://dimebox.app/api/inboxes/claim \
-H 'Content-Type: application/json' \
-H 'PAYMENT-SIGNATURE: <signed payment>' \
-d '{"slug":"acme-notices","ai_drafting_enabled": false}'See claiming a custom inbox name for the rest of what that route does, including how availability is checked before payment.
There's nothing wrong with running some inboxes drafting-enabled and others raw-only inside the same system — a marketing agent that drafts outreach from a brief, next to a billing system that only ever sends raw, pre-approved notices from a separate, drafting-disabled inbox. Because the setting lives on the inbox rather than being negotiated per call, a caller never has to carry logic to decide which mode applies — it only ever sees the one request shape that inbox accepts, and anything else is rejected automatically.
The strongest version of this guarantee is architectural, not procedural: on a drafting-disabled inbox, a purpose field fails validation before any drafting step is reached — there is no code path where a model is invoked and then its output is discarded or ignored. That's a stronger guarantee than "we instructed the system not to draft," because there's no step in the request lifecycle where drafting could happen at all for that inbox.
Because the setting is fixed at provisioning rather than exposed as a toggle on an existing inbox, changing your mind after the fact means provisioning a new inbox with the setting you actually want, rather than flipping a switch on the old one. Worth factoring into the decision up front: if there's real uncertainty about whether an agent will eventually need drafting, provisioning two inboxes — one of each — from the start costs nothing extra and avoids a migration later.