How does bulk enrichment work?
Bulk enrichment is a batch job. You compile your existing records into a flat file, usually a CSV or XLSX, and transfer it to your data supplier. The supplier runs a matching process against their reference database, appending the requested fields to each row that matches, then returns the completed file to you. The whole cycle takes anywhere from two hours for a small file of 5,000 records to two business days for a million-row CRM export.
The typical workflow has four stages:
- File preparation. Clean and deduplicate your input records. Consistent formatting of company name, postcode, and Companies House number as match keys directly affects the match rate you achieve.
- Secure upload. Transfer the file via SFTP or an encrypted supplier portal. Never send a contact file by unencrypted email; beyond the obvious security risk, it also undermines your UK GDPR accountability position.
- Match and append. The supplier's matching engine links your records to theirs. Each matched record gets the requested fields appended (job title, direct telephone, SIC 2007 code, or whatever was agreed in scope).
- Secure download. You retrieve the enriched file via the same secure channel. A good supplier includes a match report showing total records submitted, records matched, and match rate by field.
Pricing follows the matched output, not the input volume. If you submit 50,000 records and 35,000 match, you pay for 35,000 matches. Rates typically range from £30 to £80 per 1,000 matches for B2B enrichment, falling noticeably above the 100,000-record threshold. For fuller context on the underlying value case, see our guide to CRM enrichment ROI for UK businesses.
When is bulk the right choice?
Bulk enrichment makes sense when you have a defined dataset that needs enriching in one go and real-time return is not a requirement. The clearest use cases are: a quarterly or annual CRM hygiene pass, a pre-campaign list build, an account-based marketing (ABM) programme where you are enriching a fixed target-account list, and post-event lead follow-up where contacts were captured on a badge scanner or paper form.
A Leeds-based manufacturing equipment distributor enriching 12,000 existing accounts ahead of a print mail campaign would typically choose bulk. The turnaround time is acceptable, the per-record cost is lower than API, and there is no integration work required beyond SFTP credentials.
How does API enrichment work?
API enrichment is a real-time lookup. Your application sends a single HTTP request containing one or more match keys (an email address, a Companies House number, or a UK postcode plus company name), and the API responds within 200 to 800 milliseconds with the appended fields. The response is a structured JSON object, which your system writes directly into the relevant CRM record or passes downstream to a routing or scoring workflow.
The integration has three components:
- Authentication. The supplier issues an API key. All calls travel over TLS 1.2 or higher. Rotate keys on a defined schedule and never expose them in client-side code.
- Request formation. Your developer maps the available match-key fields in your system to the API's expected parameters. Better match keys produce higher hit rates; a Companies House registration number is deterministic and beats name-plus-postcode for B2B lookups.
- Response handling. Write logic to handle three outcomes: a confident match, a partial match with lower certainty, and a no-match. A no-match is not an error; it means the record is not in the reference database, and your system should flag it for a manual enrichment attempt or a future bulk pass.
API enrichment is priced per successful call (pay-as-you-go) or via a subscription tier with a monthly call allowance. Pay-as-you-go rates often sit between £0.08 and £0.25 per call for UK B2B lookups, depending on the fields returned. Subscription tiers become cost-effective once you are making 5,000 or more calls per month consistently.
When is API the right choice?
The API model is the only practical option when enrichment needs to happen in the same transaction as lead capture. If your marketing team is routing inbound leads to sales reps within 90 seconds of form submission, a batch file with a 24-hour turnaround is irrelevant. API enrichment is also the right choice for CRM integrations where new accounts are created continuously, for data quality checks at point of data entry, and for any workflow where a downstream system (a lead scoring model, a territory assignment engine, a compliance check) needs the enriched field before the next step can execute.
In our experience, SaaS businesses and high-volume lead generation operations almost always land on API enrichment for their inbound channel, even if they continue to run quarterly bulk jobs on their existing CRM base. The two delivery models are not mutually exclusive.
Bulk vs API enrichment: a direct comparison
The table below covers the key dimensions most buyers weigh when choosing a delivery model.
| Dimension | Bulk enrichment | API enrichment |
|---|---|---|
| Delivery speed | 2 hours to 2 business days (file turnaround) | 200 to 800 ms per record |
| Trigger | Scheduled or ad-hoc batch job | Event-driven (form submit, CRM write, webhook) |
| Pricing model | Per 1,000 matched records; volume discounts above 50k | Per call (PAYG) or monthly subscription tier |
| Unit cost at 100k records | Lower (typically £30-£50 per 1,000) | Higher unless subscription negotiated |
| Technical integration | SFTP credentials; no code required | REST API integration; developer time needed |
| Security mechanism | SFTP with key authentication; optional PGP file encryption | TLS 1.2+; API key authentication |
| Suitable for real-time use | No | Yes |
| Best volume range | 5,000 to 1,000,000+ records per job | 1 to 500,000+ calls per month |
| Match report provided | Yes, per job (match rate, field coverage) | Via API analytics dashboard or log aggregation |
| Typical buyer profile | Marketing ops, data teams, campaign managers | Engineering teams, RevOps, product teams |
Security considerations for each delivery model
How data moves between you and your supplier matters under UK GDPR. The Information Commissioner's Office (ICO) expects you to have "appropriate technical and organisational measures" in place (Article 32 UK GDPR). Both delivery routes can meet that standard, but the controls differ.
Securing bulk transfers
SFTP is the standard for bulk file transfer. It encrypts both the authentication credentials and the file contents in transit, and it produces an access log that documents when the file was uploaded and when it was downloaded. Your supplier should provide unique SFTP credentials per client, not a shared account. For particularly sensitive data sets, PGP encryption of the file before upload adds a second layer: even if someone intercepts the file at rest on the SFTP server, it remains unreadable without the private key.
Retain SFTP transfer logs and match reports as part of your UK GDPR records of processing. If you receive a subject access request (SAR) or a regulatory query from the ICO, these logs form part of the audit trail showing when data was received, from whom, and under what lawful basis.
Securing API integrations
Every API call must travel over TLS 1.2 or higher. Verify this in your integration, not just in your supplier's documentation. API keys should be stored as environment variables or in a secrets manager (AWS Secrets Manager, HashiCorp Vault, and similar tools are all common choices), never hard-coded in source files or committed to a public repository.
Rate limiting is a practical as well as a security concern. If your application has a bug that causes it to fire enrichment calls in a loop, both your supplier's rate-limit policy and your own monthly call budget will suffer. Implement exponential backoff and circuit-breaker logic in your integration from the start.
Data minimisation applies to both models
Under UK GDPR's data minimisation principle (Article 5(1)(c)), you should only request the fields you actually need. If your use case is B2B telemarketing, request the direct telephone number and job title. Do not request email, postal address, and personal mobile as well "just in case". This applies to both bulk jobs (scope the fields in the brief to your supplier) and API calls (only request the field groups your application will actually use).
Pricing models in practice: what you are actually paying for
The published rate card rarely tells the full story. Understanding what each pricing structure is actually measuring helps you compare suppliers accurately and build a realistic business case.
Bulk pricing: matched records, not input volume
You pay for matches, not submissions. This is the right alignment of incentives: the supplier is rewarded for having broad, accurate coverage, not for charging you for records that fall outside their database. Volume tiers typically break at 10,000, 50,000, and 250,000 matched records per order. A job of 200,000 matched records might cost £45 per 1,000 at the standard rate but £32 per 1,000 at the 100,000-record tier price, saving you roughly £2,600 on a single job.
Some suppliers add a minimum job fee of £250 to £500. For small one-off jobs under 5,000 records, this makes bulk relatively expensive per record compared to API. Below that threshold, a pay-as-you-go API arrangement often works out cheaper.
API pricing: calls, not just matches
Most API pricing charges per call, regardless of whether the call returns a match or a no-match. This is an important distinction. If your input record quality is poor and 40% of calls return no match, you are paying for those failed lookups too. Invest time upfront in data quality at the point of capture: a well-formatted Companies House number as the primary match key will return a match rate above 90% on registered UK businesses, whereas a company name alone might match at 60-70%.
Subscription tiers typically offer 10,000, 50,000, and 250,000 calls per month with a fixed monthly fee. Over-usage is either blocked (you need to upgrade) or charged at a per-call rate. Forecast your call volume for the next 12 months before choosing a tier. Under-buying means throttling at peak; over-buying means paying for unused capacity.
When does a combined approach make sense?
Running both models in parallel is not redundant. They serve different data states in your CRM:
- Existing records (bulk): your CRM base was built over months or years. A quarterly bulk refresh catches job-title changes, new direct dial numbers, and company restructures that your day-to-day API enrichment would miss because those records were created before the API integration existed.
- New inbound records (API): every lead that enters your CRM through the web form, a chatbot, or a direct sales entry gets enriched within seconds of creation. By the time the sales rep opens the record, it already has firmographic data, a direct telephone number, and a SIC 2007 code.
A recruitment technology company based in Manchester, for example, might run a monthly bulk job enriching 40,000 employer accounts with headcount bands and SIC codes for its resourcing team, while simultaneously running API enrichment on 800 inbound employer registrations a week. The bulk job costs roughly £1,600 per month; the API subscription costs £400 per month. Total enrichment spend: £2,000 per month to keep 40,000 records current and enrich every new record on arrival.
For a broader look at what enrichment should actually return in commercial terms, our article on what data enrichment is and how it works covers the fundamentals, and our CRM enrichment ROI guide walks through the financial case in detail.
GDPR compliance: does the delivery model change the rules?
No. The lawful basis analysis, purpose limitation requirements, and data minimisation obligations are identical regardless of whether enriched fields arrive in a CSV or a JSON response. What differs is the audit trail you need to maintain.
For bulk jobs, your records of processing should document: the date of transfer, the supplier's identity, the fields appended, the lawful basis relied on, and the match rate achieved. For B2B enrichment compiled under legitimate interests from public sources, the buyer must also have completed a Legitimate Interests Assessment (LIA) before using the appended data for outreach. For B2C enrichment from a fully opt-in consumer file under UK GDPR and PECR consent, the consent lineage sits with the supplier, but you remain responsible for ensuring each record's channel preferences are respected.
For API integrations, the same documentation requirements apply. Log the date the integration went live, the supplier's data processing agreement (DPA) reference, and any configuration changes that alter the fields your integration requests. If the ICO asks you to demonstrate accountability under Article 5(2) UK GDPR, these records are the evidence.