Numbers, mail and proxy traffic are charged from one account, but calculated by different logic: a number is paid per verification, mail is paid for the rental term, and traffic is paid for gigabytes pushed through. Lumping all three into one line called "infrastructure spend" is a reliable way to miss the budget. Here is how to calculate each item separately, what breakdown is typical for different loads, and what to do if the budget runs out early.
Three line items and how to calculate each one
Numbers are billed per unit: one verification is one charge, regardless of how many days you formally "hold" the number. The numbers budget follows the count of verifications per month, not the count of active lines.
Mail is rented for a term — a day, a week, a month — and the price does not depend on how many messages land in the mailbox. The mail budget follows the number of mailboxes needed at once, times the rental term, not the volume of correspondence.
Proxy traffic is billed by the gigabyte, so its budget follows the volume of pages and the frequency of requests: a text page weighs 0.3–1 MB, a product page with images is 2–5 MB, and a feed with autoplaying video eats tens of megabytes per minute. The catalogue of channel types lives in the proxy section.
A typical breakdown for three load profiles
One-off tasks. A handful of sign-ups a month, one or two mailboxes for a short term, minimal monitoring: 5–15 verifications, 1–2 mailboxes for a few days, traffic within 0.3–0.5 GB. Numbers are the main line item here, since the other two stay minimal.
Regular work. One operator running the task continuously: 50–150 verifications a month, 5–10 mailboxes on monthly rental, daily monitoring of a hundred pages adding up to 1.5–3 GB a month. The three items become comparable in weight, and this is the profile where the forecast is missed most often, by saving on the wrong direction.
Team-scale operation. Several operators in parallel: 500–1000+ verifications, 30–50 mailboxes on continuous rental, and a thousand product-card checks alone already run 3–5 GB — at team scale the monthly count reaches tens of gigabytes. Mail and traffic overtake numbers here, since both scale with the number of parallel profiles rather than one-off actions.
Why traffic is planned from task volume and numbers from verification count
These two line items have a different nature of spend. A number is a discrete unit: one confirmation code costs a fixed amount whether the verification took a second or several retries. Traffic is continuous spend: a gigabyte is charged as data is pushed through, and an autoplaying video feed burns a budget faster than a hundred text pages. Planning numbers by "how many gigabytes" makes as little sense as planning traffic by "how many verifications" — each line item needs its own native unit.
A reserve for retries and failed directions
Some verifications fail on the first try — the direction is busy, the code never arrives, the platform rejects the number — and the retry is charged separately. The same applies to traffic: a dropped session or a captcha forces the page to load again, and a failed attempt does not refund the gigabytes spent. A sensible reserve is 10–15% on top of the calculated sum for each line item, not one general "cushion" for the whole budget: without a breakdown, the reserve ends up covering whichever item overran first, not the one that needed it.
What to do about a mid-month overrun
Start by checking the debit history by product, not the total balance: an overrun is almost always concentrated in one item, not spread across all three. If it is traffic, that is the most elastic line item: disable image and font loading, or cut monitoring frequency, without stopping the task — but cut spend deliberately, not by switching to the cheapest channel; cheap versus expensive proxies explains where the savings turn out illusory. If it is numbers, check whether failed verifications are rising for one direction: serial failures usually mean a problem with the direction, not the volume. Mail resists quick optimisation mid-month, since rental is already paid upfront — plan its share conservatively from the start.
Frequently Asked Questions
How do I tell which of the three line items will take up most of the budget?
Look at what scales fastest with the task: if the load is parallel accounts, mail and traffic lead; if the load is one-off actions with no continuous presence, numbers lead.
Can the budget be calculated in advance as one lump sum without a breakdown?
It can, but the first overrun leaves you guessing what to cut: a budget split into three line items is the only way to see which direction went over plan, not all of them at once.
Should the reserve be the same size across all three load profiles?
No, the reserve share grows with the number of parallel directions: 10% is usually enough for a one-off task, while a team-scale operation with dozens of profiles needs closer to 15%.
Current verification rates and the remaining budget on your account are in the number rental section.