CSV file delivery vs API: when to choose which

What does each delivery method actually involve?

The terminology sounds technical but the mechanics are straightforward. A CSV (comma-separated values) file is a plain-text spreadsheet where each row is one record and each column is a data field: company name, contact name, job title, direct telephone, business email, postcode, UK SIC 2007 code, and so on. You receive the file once, import it, and that is the end of the transaction unless you order a refresh.

An API (application programming interface) is a live connection. Your system sends a request to the supplier's endpoint, typically something like GET /v1/enrich?company=Acme+Ltd&postcode=LS1+4AP, and receives a structured response in JSON or XML containing the matching record. The call takes milliseconds. It is always current because the supplier's database is queried in real time rather than at the point a file was exported.

The fundamental trade-off is predictability versus freshness. A CSV gives you a fixed, auditable asset. You know exactly what you received, when you received it, and what you paid. An API gives you data that reflects the supplier's universe at the moment of the call, which matters when phone numbers or job titles change frequently. UK B2B contact data decays at roughly 25–30% per year, so a CSV pulled in January may have a 10% inaccuracy rate by June.

How does each workflow operate, and what are the security implications?

The CSV workflow

The standard sequence for a UK data supplier sending a CSV file runs like this. You agree a data brief: fields required, volume, segmentation criteria (for example, Operations Directors at logistics firms in the Midlands with 50–500 employees). The supplier builds and quality-checks the file, then uploads it to a secure SFTP server or a password-protected download portal. You receive access credentials by a separate channel (never in the same email as the file link). You download, import into your CRM or campaign platform, and begin suppression washes against the Telephone Preference Service (TPS) for telephone channels or the Mailing Preference Service (MPS) for direct mail.

From a security standpoint, the weak points in a CSV workflow are transit and storage. The file must travel over an encrypted channel. Plain email attachment is not acceptable under UK GDPR Article 32, which requires appropriate technical measures to protect personal data in transit. Reputable suppliers use SFTP (SSH File Transfer Protocol) with TLS-encrypted connections, or portals enforcing TLS 1.2 as a minimum. Once downloaded, your organisation becomes the data controller for that file and bears responsibility for its storage, access controls, and eventual deletion at the end of the retention period you specified in your data licence agreement.

The API workflow

API delivery is request-driven. You write code (or configure a no-code tool like Zapier, Make, or HubSpot's workflow engine) to call the supplier's endpoint whenever a trigger fires. Typical triggers include a new lead submitting a web form, a sales rep manually requesting enrichment on a CRM record, or a nightly batch job enriching all records added in the previous 24 hours.

Authentication is almost always API key-based: a bearer token included in the HTTP Authorization header. The supplier ties that key to your account, applies rate limits (commonly 5–20 requests per second for standard tiers), and logs every call. That call log is an audit trail for your data-processing register under UK GDPR Article 30. Some enterprise setups use OAuth 2.0 where multiple internal teams share a single contract but need separate usage attribution.

Security considerations for API delivery differ from CSV. There is no file to store or delete, which removes the at-rest risk. The ongoing risk is key compromise: if your API key is exposed (a common problem when keys are hard-coded into front-end JavaScript or checked into public Git repositories), an attacker can query the supplier's database at your expense and in breach of your licence. Store API keys in environment variables or a secrets manager, not in source code.

CSV vs API: a direct comparison

How much does integration effort actually differ?

This is where many buyers underestimate the API option. A CSV import into a CRM like Salesforce, HubSpot, or Microsoft Dynamics takes a competent marketing operations person two to four hours: map the column headers to CRM fields, handle duplicates, run a suppression wash, and click import. There is no code. The file either imports cleanly or it surfaces errors you fix in a spreadsheet.

An API integration is a software project. Even a simple enrichment call requires writing or configuring: the HTTP request, error handling (what happens when the API returns a 429 rate-limit error or a 404 no-match?), field mapping from JSON to CRM fields, deduplication logic, and retry logic for transient failures. A competent developer can build this in one to three days for a straightforward use case. If the trigger is a HubSpot workflow calling a Zapier webhook calling the API, a no-code operator can assemble it in a day, but the maintenance burden when the supplier changes their API version falls entirely on your team.

There is a middle option that buyers overlook: some suppliers offer a managed batch enrichment service that sits between pure CSV and pure API. You submit a file of company names and postcodes (or a CRM segment), the supplier runs enrichment against their live database and returns an enriched file within 24 hours. You get near-current data without writing a line of code. Costs are typically £0.08–£0.25 per matched record, with a minimum order. See our guide on bulk versus API enrichment approaches for a detailed breakdown of that comparison.

What does the combined approach look like in practice?

A Manchester-based B2B SaaS firm targeting HR Directors at UK professional services firms with 100–1,000 employees might run this pattern. At contract start, they take a CSV file of 8,000 matching contacts, verified telephone and email, compiled under legitimate interests from publicly available sources. The file is imported into HubSpot over a weekend. Suppression against TPS is run on the telephone field before any calls are made. That covers the outbound prospecting programme for the next 12 months.

In parallel, the firm integrates the supplier's enrichment API into their website demo-request form. When a prospect submits the form with their company name and email domain, the API fires, returns job title, direct line, and LinkedIn URL, and populates the CRM record before it hits the sales queue. The API call volume is modest: roughly 200–400 per month. At £0.20 per call, that is £40–£80 per month, completely separate from the CSV licence fee.

In our experience, this dual-mode approach delivers the best cost-per-qualified-lead outcome for UK B2B teams: the CSV covers the known universe of prospects at low unit cost, and the API handles the inbound channel where speed of enrichment directly affects sales conversion.

Are there alternatives beyond CSV and API?

Three formats come up regularly in conversations with larger buyers.

JSON and XML file delivery. These are structured alternatives to flat CSV. JSON is common when the receiving system is a web application or data warehouse expecting nested objects rather than flat rows. XML appears in legacy enterprise integrations. For most UK marketing and sales operations teams, there is no practical advantage over CSV: the data fields are identical, only the format differs. If your CRM's import tool accepts CSV but not JSON, stick with CSV.

Direct database connection. Larger buyers with data warehouse infrastructure (Snowflake, BigQuery, Redshift, or similar) sometimes negotiate a read-only SQL endpoint or a data share, refreshed nightly or weekly. This gives automated currency without per-call API charges and without the manual import cycle of CSV. It is priced differently, usually as a flat annual licence tied to the volume of the shared view. The integration work is handled by a data engineer rather than a marketing ops person, and the supplier's security review process is more thorough because the access window is persistent rather than transactional.

Tab-delimited (TSV) and fixed-width formats. These survive mainly in legacy CRM and marketing automation imports. If your platform requests TSV rather than CSV, any competent UK data supplier can deliver in that format at no extra cost. Fixed-width files (where each field occupies a defined character position) are still required by a small number of older mailing house systems. Mention it during the data brief and the supplier will handle it.

For a broader view of what to specify when placing a data order, including format, field selection, and licence terms, see our guide on how to buy marketing data in the UK.

Which should you choose?

The answer depends on three questions: volume, timing, and technical capacity.

If you are loading a prospect universe of more than 5,000 records for a campaign that runs over weeks or months, CSV is the right call. The unit economics are better, the import process is well understood, and the operational burden is a single afternoon of data admin.

If you need records enriched in real time, under 30 seconds from trigger to CRM, and your team includes someone who can write or configure an API integration, the API is the right call. Pay-per-call pricing scales naturally with lead volume and you never hold a large file of personal data in your import queue.

If neither fits cleanly, ask your supplier about managed batch enrichment. You avoid both the at-rest file risk and the integration build, in exchange for a 12–24 hour turnaround rather than instant results.

One thing to avoid: choosing API purely because it sounds more modern. A well-run CSV campaign to a verified, TPS-washed telephone list will outperform a poorly integrated API enrichment workflow almost every time. The format is a logistics decision, not a quality signal.