Salesforce Email Verification: Apex, Flow, and Data Loader Integration Patterns for 2026

Salesforce holds the single largest concentration of B2B contact data in most organizations, which makes verification inside Salesforce disproportionately important for overall deliverability. This guide covers the four practical patterns (Apex callout, Flow HTTP, Data Loader, Batch Apex), the exact code and Flow configuration for each, and the governor limit rules that decide which pattern fits which volume tier.

Why Salesforce Verification Is Different

Salesforce is not just another CRM. It sits at the center of most B2B revenue operations, which means the contact data inside Salesforce flows outward to marketing automation, sales sequencing, ABM platforms, customer success tools, and the ESP itself. A bad address inside Salesforce becomes a bad address across the entire go-to-market stack, and it stays there indefinitely because Salesforce is treated as the source of truth.

The verification problem is also unusual because Salesforce has strict runtime limits. You cannot naively loop through 100,000 Leads and call an external API for each one from a trigger; the transaction fails on the callout limit. Every practical Salesforce verification pattern is shaped around these constraints, which is why the four patterns below exist as distinct approaches rather than variations on one theme.

The Four Patterns and When to Use Each

The right pattern depends on when the verification needs to happen and how many records are involved. Most mature Salesforce orgs run more than one in parallel: real-time on new Leads, Batch Apex on quarterly re-verification, and Data Loader for one-time cleanup when the org onboards a new list.

Pattern 1: Apex Callout on Lead Insert

The most direct pattern is a Lead trigger that fires a callout to the verification API when a new Lead is created. Because triggers cannot make synchronous HTTP callouts from a DML transaction, the pattern uses a Queueable (or @future method) to defer the callout to a separate transaction. The Lead is created immediately; the verification result populates a moment later.

The endpoint the trigger calls is the standard real-time email verification API, which returns results in about 400ms per call. That timing matters for the callout budget math later in this guide.

The complete trigger and callout class:

trigger LeadVerificationTrigger on Lead (after insert) {
    Set<Id> leadIds = new Set<Id>();
    for (Lead l : Trigger.new) {
        // Skip if no email or already verified via upstream integration
        if (String.isNotBlank(l.Email) && l.BEC_Verified_At__c == null) {
            leadIds.add(l.Id);
        }
    }

    if (!leadIds.isEmpty()) {
        // Defer to Queueable so we can do HTTP callouts safely
        System.enqueueJob(new BECVerifyLeadsQueueable(leadIds));
    }
}

public class BECVerifyLeadsQueueable implements Queueable, Database.AllowsCallouts {

    private final Set<Id> leadIds;

    public BECVerifyLeadsQueueable(Set<Id> leadIds) {
        this.leadIds = leadIds;
    }

    public void execute(QueueableContext ctx) {
        List<Lead> leads = [SELECT Id, Email FROM Lead WHERE Id IN: leadIds];
        List<Lead> toUpdate = new List<Lead>();

        for (Lead l : leads) {
            HttpRequest req = new HttpRequest();
            req.setEndpoint('callout:BEC_API/real-time/?email=' + EncodingUtil.urlEncode(l.Email, 'UTF-8'));
            req.setMethod('GET');
            req.setTimeout(10000);

            try {
                HttpResponse res = new Http().send(req);
                if (res.getStatusCode() == 200) {
                    Map<String, Object> body =
                        (Map<String, Object>) JSON.deserializeUntyped(res.getBody());

                    l.BEC_Status__c = (String) body.get('status');
                    l.BEC_Is_Disposable__c = (Boolean) body.get('isDisposable');
                    l.BEC_Is_Role_Account__c = (Boolean) body.get('isRoleAccount');
                    l.BEC_Verified_At__c = Datetime.now();
                    toUpdate.add(l);
                }
            } catch (Exception e) {
                System.debug(LoggingLevel.ERROR, 'BEC verify failed: ' + e.getMessage());
            }
        }

        if (!toUpdate.isEmpty()) {
            update toUpdate;
        }
    }
}

The pattern relies on three custom fields on Lead (BEC_Status__c, BEC_Is_Disposable__c, BEC_Is_Role_Account__c, BEC_Verified_At__c) plus one Named Credential (BEC_API) that stores the API key and endpoint. Named Credentials are covered later in this guide because they change how the security posture of the entire integration works. Full response field details are in the email verification API documentation.

Pattern 2: Flow HTTP Callout (No Code)

Salesforce introduced HTTP Callout as a Flow action in Winter 24, which means admins can now build verification integrations without writing a single line of Apex. The pattern is functionally equivalent to the trigger + Queueable above but sits entirely inside Flow Builder.

The setup takes 30 minutes for an admin who has built a Flow before:

The Flow HTTP pattern moves verification from developer land to admin land. RevOps teams that used to wait quarters for engineering bandwidth can now ship verification the same day they need it.

Pattern 3: Data Loader Bulk Cleanup

When the goal is to clean an existing database (not verify new records as they arrive), Data Loader is the right tool. This pattern completely sidesteps governor limits because the verification happens outside Salesforce; only the final field updates go through Salesforce APIs.

The workflow: export Contact and Lead Ids plus Email addresses via Data Loader, run the exported CSV through the bulk email verifier, download the enriched results file, and use Data Loader Update with matched Ids to write the verification data back. A million-row Contact table cleans in a few hours end-to-end.

Before running the full export, spot-check a handful of specific addresses through the quick email verifier to confirm the field mappings you plan to update match the response fields being returned. This 30-second sanity check prevents Data Loader Update mistakes at scale.

Pattern 4: Scheduled Batch Apex

Batch Apex is the pattern for ongoing periodic re-verification. Salesforce splits Batch Apex into scopes of 1-200 records; each scope runs as its own transaction with its own governor limits. This means a Batch job can verify tens of thousands of records overnight without hitting the 100-callout-per-transaction limit.

The Batch class implements Database.AllowsCallouts, iterates through Contacts whose BEC_Verified_At is older than 90 days, and re-verifies each. Batch size should be set to 90 (below the 100 callout limit) rather than the default 200. A weekly schedule at 2 am handles most orgs; nightly for high-decay lists.

Field Mapping and Custom Objects

The verification response has more fields than most orgs want to add to Lead and Contact. The pragmatic pattern: add four fields to Lead and Contact (Status, Is_Disposable, Is_Role_Account, Verified_At), and if you need historical verification data, create a Verification_History custom object with a Master-Detail to Lead or Contact.

The four-field minimum:

Governor Limits That Actually Matter

Every integration pattern above is shaped by three specific limits. Ignore them at your own risk.

Named Credentials for API Key Security

Hardcoding the API key in Apex classes or Custom Settings is a security anti-pattern. Named Credentials store the key encrypted at the org level and inject it automatically into the callout URL, which means the key is never visible in code, debug logs, or metadata deployments.

The setup: create an External Credential with Custom authentication protocol, add a Named Principal with the API key in a header or query parameter, and create a Named Credential pointing to https://api.bulkemailchecker.com. The Apex code references it as callout:BEC_API without ever seeing the actual key.

For agencies managing verification across multiple client orgs, Named Credentials also simplify sub-account management. Each client org gets its own Named Credential pointing at the shared verification service, which pairs well with email verification for teams features for centralized credit management.

Frequently Asked Questions

The Bottom Line

Salesforce email verification is not one integration; it is four integrations that fit different scenarios. Real-time patterns (Apex or Flow) handle new records as they arrive. Bulk patterns (Data Loader) clean the existing database in one operation. Scheduled patterns (Batch Apex) keep the database clean over time. Mature orgs run more than one in parallel.

The pattern that matters most for most orgs is the Flow HTTP callout because it removes developer dependency from the day-to-day. Once Named Credentials are in place and the Flow is built, the admin team owns the verification workflow permanently. Engineering only gets involved for the initial security setup and any custom logic that Flow cannot express.