Bento API notes
What actually happens to a message once Mimeo hands it to Bento. For connecting Bento in the first place, see Bento setup.
You don't call Bento directly
There's no Bento-specific endpoint in the Mimeo API. You send events and trigger sends the same way regardless of provider; the provider layer translates. This page exists because Bento's behavior is visible in the resulting emails, and you should know what you're looking at.
Bento modifies your sent messages
Two things arrive in the delivered email that Mimeo didn't put there.
UTM parameters on links
Bento appends its own UTM parameters to links in messages it sends. That has two consequences worth planning for:
- Your analytics will attribute the traffic to Bento's parameters unless you set your own. If a link already carries explicit UTMs, set them deliberately rather than leaving attribution to whatever Bento adds.
- The landing URL your visitor sees has extra query string on it. If your destination does exact URL matching on anything, account for the additional parameters.
Bento's own open pixel
Bento injects its own tracking pixel on API sends, in addition to Mimeo's. Both are present in the delivered message, and both measure independently.
The numbers will not match, and that's expected. Mimeo filters known scanners and click bursts out of its stats; Bento applies its own rules to its own measurement. Mimeo's tracking is the authoritative one for your instance — it's what the timeline, the person record, and every stat in the app are built on.
Rate limits
Mimeo batches and paces sends to stay inside Bento's limits automatically. There's nothing to configure.
| Limit | Value |
|---|---|
| Emails per request | 60 |
| Emails per minute | 60 |
The practical consequence: a large send is paced, not instant. Plan around throughput rather than expecting the whole list to go out at once.
Suppression
Push
When someone unsubscribes through the subscription API, Mimeo records it locally first and then pushes the opt-out to Bento through its commands API. Both sides end up agreeing, but the local record is the one that governs whether Mimeo sends.
Pull
Bento has no webhooks, so nothing is pushed back to you. Mimeo reads per-address suppression state by polling:
- Lazily — when you open a person who was emailed recently, their suppression state is refreshed then.
- Nightly — a sweep reconciles the rest.
So provider-side suppressions surface within about a day, or immediately for anyone you happen to look at.
Silent drops
Bento accepts sends to addresses it has suppressed and then drops them without an error. Your send log will show acceptance. This is the concrete reason the send log is documented as acceptance, not delivery — combine it with suppression state before concluding a message arrived.
List-Unsubscribe headers
Bento injects its own RFC 8058 List-Unsubscribe headers, which
is what produces the native unsubscribe button in Gmail and Apple Mail. Those
resolve to Mimeo's
one-click endpoint
(POST /u/:token), so a header unsubscribe lands in your instance
with the same record and attribution as one from your own page.
Deletion
Bento exposes no deletion API. Erasing a person in Mimeo for a GDPR request cannot remove them from Bento, so Mimeo raises a manual-cleanup notice telling you what to delete there yourself. See People for the full erase behavior.