Inboxes for EmailBison

EmailBison attracts a particular kind of operator: one who would rather hold the instance, the data and the API key than rent a dashboard, and who tends to run enough mailboxes that adding them one at a time stopped being an option a long time ago. If that is you, the interesting part of this page is not the connection steps, which are short, but the fact that the whole fleet can be ordered, built, exported and monitored from code, with EmailBison as the destination.

We sell the infrastructure underneath the sequencer, not the sequencer, and this page is not a review of it. The claims here are about our mailboxes, our API, and the hand-off between the two and your instance, every one of which you can check.

EmailBison is addressed by an API key and the base URL of the instance, and that is exactly what our export needs. Save both once in the portal under sequencer keys, or through the API, and they are used for every export after that and never shown back. A hosted instance and a self-hosted one differ only in the URL.

The full reference is published verbatim at /transactional-api.md and the onboarding sequence on the developers page; this is the shape of a run that ends with mailboxes in EmailBison.

1. 1Create the account and issue a key. The key is made in the portal under Settings → API keys and shown once; scopes are read, write and orders:place. A test key runs the same routes against a sandbox where nothing is charged, so the whole flow below can be rehearsed before a live key exists.
2. 2Save the EmailBison key and base URL. Once, against the account. Every export after that refers to it by id.
3. 3Preview, then place. Preview the order spec and read the price and the warnings back before placing. Place with an idempotency key, name the sequencer as emailbison, and the export is queued for when the build completes.
4. 4Follow the build and the export. Orders report their build state; exports report theirs, including the failed ones, which is where a wrong base URL shows up. Both are readable from the API, the CLI and the MCP server, so an assistant can tell you the mailboxes are in without you opening a tab.
5. 5Set caps, names and signatures in EmailBison. Per mailbox, before the first send. The cap is the setting that decides how long the fleet lasts; everything else is cosmetic by comparison.

The infrastructure recipes are costed order specs for common volumes, each checked against the planner at build time, so an agent can start from one rather than from a blank spec.

• Real mailboxes, your admin. Every inbox is an official Google Workspace, Microsoft 365 or Azure mailbox, and the credentials in your portal connect to EmailBison the way any business mailbox does: the Google path for Google, the Microsoft path for Microsoft 365 and Azure, OAuth where offered.
• SMTP AUTH on Microsoft. If you connect over IMAP/SMTP, authenticated SMTP is off by default on recent Microsoft tenants and fails looking like a wrong password. Enable it per mailbox, or use OAuth and never meet it.
• Authentication already published. SPF, DKIM, DMARC and forwarding are configured before handover; confirm with the authentication checker.
• Two-factor decided. Disable 2FA on the receiving account before delivery, or keep it on and grant restricted access to [email protected]; orders where neither has happened take longer than 48 to 72 hours.

Fleets run from code are the ones most at risk of a cap being raised in a config file and never lowered, because nobody looks at the file again. Put the cap in the order spec’s notes, size the fleet for the volume you want with the calculator, and scale by adding mailboxes through the API rather than editing the number.

Pause it in EmailBison so the campaign reroutes across the fleet, read the deliverability route on our API for that domain, run the bounce analyzer on its bounces to tell a list problem from a domain problem, and message us on WhatsApp at +1 904 736 2539. Replacement inboxes are part of the package when deliverability drops, and a replacement order can be placed from the same API call shape as the first one.

Prewarmed inboxes include a free prewarmed .COM or .CO domain and send from the day they land: $8.00 per inbox per month on Google and Microsoft, $7.00 on a two-month commit, $6.00 quarterly. Azure is billed per tenant, $69 monthly, $60 on two months, $50 quarterly, with up to 100 inboxes on one domain, which at capacity is $0.69, $0.60 and $0.50 per inbox. Fresh inboxes on your own domains run $3.50 to $2.00 per inbox per month on Google, $3.00 to $2.00 on Microsoft 365, and $50 flat for an Azure tenant. The API returns the same prices in a preview, and every price on the site is at /price.md.

Can you push the inboxes into EmailBison for me?

Yes. EmailBison is one of the four sequencers our portal and API export into. Save your EmailBison API key and base URL once under sequencer keys, and a built order can be exported straight into your instance, self-hosted or not. You hold full admin on every mailbox regardless, so the credentials we hand over also import manually.

What do you need from my EmailBison account?

An API key and the base URL of your instance. That is all the export uses; there is no login to share. If you run EmailBison yourself, the base URL is your own host, which is why we ask for it rather than assuming one.

Can I order and export without touching the portal?

Yes. The transactional API and MCP server at api.warminboxes.com place orders, follow the build, and start and follow exports, with the same rules as the portal. Preview an order before placing it, use an idempotency key, and never pass a sequencer password through an assistant; the sequencer-keys route stores it once. The developers page walks the sequence.

What daily limit should each mailbox have in EmailBison?

Fifteen a day on Google Workspace, eight on Microsoft 365, two on a full Azure tenant of 100, four at 50 per tenant, six at 25. These are the paces the calculator sizes fleets on; the provider ceilings are far higher and irrelevant to cold email.

Do prewarmed inboxes need EmailBison warmup?

No. The sender history is already built and our warmup keeps running at 30 emails per inbox per day underneath your campaigns for as long as you hold the inboxes. A second warmup is more mail from the same mailbox against the same daily budget; leave it off, or count it inside the cap.

How long until the mailboxes are in my instance?

Orders are delivered within 48 to 72 hours of payment, prewarmed and fresh alike, with SPF, DKIM, DMARC and forwarding configured first. The export runs as part of the build when your key and URL are saved, and you can follow it from the portal or the API until it reports done.