Which credit bucket does the API consume from (monthly or PAYG)?

API requests on Valid Email Checker draw from the exact same credit pool that powers your dashboard verifications, bulk uploads, and integrations. There is no separate API-only balance, no quota, no add-on package. Whatever credits are on your account at the moment of the request are what gets spent — one credit per verified address, regardless of which endpoint you hit.

The three buckets

Your credit balance is actually split across up to three buckets internally, and the API consumes them in a fixed order:

The order is enforced server-side and is identical across every credit-spending surface on the platform. Dashboard verifications, bulk uploads, the free email-checker tool, and API requests all walk the buckets in monthly → rollover → payg order. See does the API consume monthly credits first for a worked example.

Why monthly first

Monthly credits expire at the end of the billing cycle if you have not used them. Pay-As-You-Go credits never expire. Burning monthly first protects your never-expiring stash for when you actually need it — say, during a month when you skip the subscription. If we drained PAYG first, every cycle would forfeit unused monthly credits while your PAYG stash sat unused, which is the opposite of what most customers want.

What the API response tells you

The /verify-single response body includes credits_used: 1 to confirm one credit was deducted, but does not break down which bucket it came from. To see the per-bucket impact, open the Credits History screen in your dashboard — every API request gets logged as a verify_single_api or verify_bulk_api entry with a per-bucket deduction breakdown.

Mixed deductions

A single bulk task with thousands of addresses can straddle multiple buckets. If you have 100 monthly credits remaining and the bulk task verifies 500 addresses, the deduction logic spends the 100 monthly credits first, then takes the remaining 400 from your PAYG bucket. The whole transaction shows as separate ledger entries so you can trace exactly where each credit came from.

Running low on monthly with API traffic

If you are on a monthly subscription and your API integration is hammering the verify endpoint, you might burn through the monthly allotment well before the billing cycle ends. At that point the API automatically rolls onto your PAYG bucket. No reconfiguration is needed; the next call just keeps working. If both buckets drain to zero, the API returns 402 Insufficient credits — see what error code does the API return when out of credits.

Next steps