What does the `bulk_verification` transaction type in Credits History mean?

A bulk_verification row in your Valid Email Checker Credits History records the credits spent on a bulk CSV upload from the dashboard. Each upload that processes against your credits produces one or more bulk_verification rows depending on how many credit buckets the job touched. The row tells you how many credits the job cost and where they were drawn from.

Row anatomy

A typical entry shows: transaction type "Bulk Verification", credits_in = 0, credits_out equal to the number of credits taken from a single bucket, balance_after equal to the running total after that bucket's portion was deducted, bucket = "monthly" or "payg" (or "rollover" on legacy accounts), description usually referencing the task name or file name. A red downward arrow icon indicates the row is a deduction rather than a credit.

A single bulk job can produce multiple rows

This is the most common source of confusion. A 10,000-email upload that drains your Monthly bucket dry and then dips into PAYG will produce two bulk_verification rows — one with bucket "monthly" for the portion taken from Monthly, one with bucket "payg" for the rest. Same timestamp, same description, same transaction type. The total credits used equals the sum of the two rows. This happens because VEC follows the credit consumption order and logs each bucket touched separately so the ledger is precise.

Refunds for Unknown results land as separate rows

If your bulk job included rows that came back Unknown, the auto-refund for those does not modify the original bulk_verification row. Instead, a separate refund row is logged with credits_in equal to the refunded amount, returning the credit to the bucket it was originally drawn from. See what does refund mean for the details.

How this differs from api_bulk_verification

A separate transaction type, api_bulk_verification, exists for bulk jobs submitted through the public API. The two are nearly identical in behavior — same deduction logic, same auto-refund — and the only practical difference is which one tags the row. If you submit a bulk job through the dashboard UI you get bulk_verification. Through the API endpoint, you get api_bulk_verification.