Running a large test matrix, need thousands of long-lived test inboxes, a dedicated plan, an SLA, or something the self-serve API doesn't cover yet? Tell us about your use case and we'll follow up by email.
Ask for thousands of test inboxes in one API call instead of creating them one by one — for a seeded QA environment, a load test, or a signup regression that runs for weeks. The job is accepted straight away and the inboxes are created in the background; you follow it, then download the address list.
# 1. Ask for 10,000 numbered inboxes that live 90 days
curl -X POST https://otpbox.io/api/v1/provisioning-jobs \
-H "authorization: Bearer $OTPBOX_KEY" \
-H "content-type: application/json" \
-d '{ "count": 10000, "lifetime": "90d",
"pattern": "qa-{n}", "domain": "qa.example.com" }'
# → 202 { "id": "prov_...", "status": "queued", "pattern": "qa-{n:5}", ... }
# 2. Follow it (or subscribe to the provisioning.completed webhook)
curl https://otpbox.io/api/v1/provisioning-jobs/prov_... \
-H "authorization: Bearer $OTPBOX_KEY"
# → { "status": "completed", "createdCount": 10000, "progress": 1, ... }
# 3. Download the address list (add ?format=json for JSON)
curl -o pool.csv https://otpbox.io/api/v1/provisioning-jobs/prov_.../export \
-H "authorization: Bearer $OTPBOX_KEY"
# address,inbox_id,created_at,expires_at
# qa-00001@qa.example.com,...
# qa-10000@qa.example.com,...Numbered (qa-00001 … qa-10000), random tails, or a fixed prefix — on any verified custom domain of your organization.
Pool inboxes belong to the project, so every key in it can read them with /otp and /wait. Rotating a key doesn't orphan a pool.
Poll the job, watch the dashboard's Provisioning page, or get a provisioning.completed webhook. Export the list as CSV or JSON.
Release a pool early to end every inbox at once. At the end of its lifetime it expires in bulk and provisioning.expired fires once.
The live pool is measured every 15 minutes: 10,000 inboxes held all day are 10,000 inbox-days. Usage per billing cycle in the dashboard and the API.
Your agreement can cap how long pool messages are kept (N days) and how many each inbox keeps (only the newest N).
Pricing. Pools are priced per inbox-day in your agreement, which also sets the largest pool you can hold, the longest lifetime a pool may have, and can include a monthly inbox-day allowance. One job runs at a time per organization.
For a pool, say roughly how many inboxes you need, for how long, and on which domain. Otherwise, whatever you're trying to do.
← Back to API docs