Sending emails via API in GDPR compliance

In brief: Connecting your CRM to a sending API does not make any GDPR obligation disappear. Legal basis, proof of consent carried in the call, payload minimisation, key security and a processing contract: the five points to lock down in your integration.

The day you connect your CRM to a sending API, something changes in your organisation. Emails no longer go out when a human clicks “send”. They go out when a technical condition is met. A form submitted, an opportunity status changed, a basket abandoned, an invoice issued.

It is convenient. It is also the moment when GDPR compliance stops being a marketing topic and becomes an architecture topic. Because an automated process cannot be caught after the fact: it replays the same mistake a thousand times before anyone notices.

What the API really changes in your sending chain

A web emailing interface imposes a rhythm. You import a file, you check the segmentation, you proofread, you schedule. Each step is a human checkpoint, however informal.

The API removes those checkpoints. Your application calls an endpoint, passes a recipient and some content, receives a message identifier. A few hundred milliseconds. Nobody has proofread anything.

This sending mode generally covers three families of use. Transactional emails first, triggered by a user action: order confirmation, password reset, acknowledgement of receipt. Campaigns driven from a third-party tool next, when the CRM remains master of the data and the emailing platform serves only as a sending engine. Marketing automation scenarios finally, where the API carries events rather than messages.

In all three cases, one thing does not move. You remain the data controller within the meaning of the GDPR. The API provider, for its part, is a processor. This allocation is not negotiable; it follows from who decides the purposes and the means. And you are the one who decides whom you write to and why.

The legal basis does not evaporate because sending is automated

First classic mistake: assuming that a transactional email falls outside the prospecting framework. Sometimes it does, often it does not. Everything depends on the actual content of the message, not on its name in your code.

In French B2B prospecting, the applicable regime is that of article L.34-5 of the Code des postes et des communications électroniques (the French Postal and Electronic Communications Code). It allows sending without prior consent, but under three cumulative conditions. The address must be professional and personal, tied to the position held. The subject of the message must relate to the recipient’s professional activity. And every send must include a simple and free means of objecting to subsequent sends.

This third condition deserves a pause, because it has a direct technical translation. An email sent by API with a minimalist template, without a footer, without an unsubscribe link, is non-compliant. It does not matter that it was triggered by an internal webhook at three in the morning.

For everything that falls under B2C or a database collected through a form, consent becomes the reference legal basis again under article 6 of the GDPR. The general framework is detailed in our article on data protection in emailing, which lays the legal foundations that this article applies to the technical case.

Carrying proof of consent in the call itself

This is the point most integrations miss, and it is expensive in the event of an inspection.

You collected consent somewhere. A form, a trade show, a qualified import. That proof lives in your CRM. Then your application calls the sending API, passing an email address, a first name, a campaign identifier. And that is all.

Six months later, the person complains. You have to demonstrate that consent existed at the time of sending. You open the CRM, where the record may have been modified in the meantime. You open the sending platform, which knows nothing about the origin of the contact. Neither system carries the complete information.

The remedy comes down to three fields to pass along in the payload, then store on the platform side:

These fields are not used for sending. They are used the day someone asks you to justify. All platforms accept custom attributes on contacts; the only question is deciding to fill them in before the need arises.

Push only the data the send needs

The minimisation principle of article 5 of the GDPR applies field by field, including inside a JSON request body.

In practice, integrations built quickly transmit the entire CRM record because it is simpler than choosing. The account’s turnover, the lead score, the sales rep’s notes, the date of the last call, the reason the last opportunity was lost. All of that goes off to a third-party system that has no use for it.

Three consequences. You increase the exposed surface if the platform is compromised. You create a data transfer with no declared purpose, which is hard to justify in your register. And you multiply the places where a right to erasure has to be exercised.

The sorting rule is simple: a field goes out only if it is used in the template, in the segmentation, or in the triggering logic. The rest stays with you. A personalisation variable that appears nowhere in the message has no business being in the call.

What your architecture must provide for from the design stage

An unsubscribe that flows back in both directions

This is the most frequent synchronisation flaw, and the most visible to the recipient.

Someone clicks the unsubscribe link in an email. The sending platform records the objection. Your CRM, for its part, knows nothing. A fortnight later, a new scenario is triggered from the CRM, calls the API with that same address, and the person receives a message they had explicitly refused.

Two mechanisms prevent this scenario. A webhook on the platform side that notifies your application at every unsubscribe and updates the status in the source system. And a check on the sender side that queries the contact’s status before calling the sending endpoint, rather than trusting a local cache.

One point of vigilance: serious platforms block sending to an unsubscribed contact and return an explicit error code. Your code still needs to read that error code instead of logging it silently.

API call logs with a decided lifespan

Your API logs contain personal data. Email addresses, calling IP addresses, personalised content, sometimes complete payloads kept for debugging. They are processing operations like any other, subject to the storage limitation principle.

Nobody ever defines their retention period. They accumulate, get backed up, get replicated, and become the first forgotten place during an erasure request.

Set a duration, document it, purge automatically. For technical operating logs, a few months are enough in most contexts. If you keep them longer for evidentiary reasons, truncate the payloads and keep only the necessary metadata.

A map of the flows for your register

Article 30 of the GDPR requires keeping a record of processing activities. An API integration creates a flow that must be described there: which data goes out, to which provider, in which country, for what purpose, with what retention period.

The exercise looks administrative. Above all, it is revealing. It is by drawing the chain from CRM to API to platform to recipient that most teams discover fields transmitted for no reason, or a test environment fed with production addresses. That last point comes up very often, as it happens. Testing a sending scenario with real customer contacts constitutes processing outside the stated purpose, and nobody ever declares it.

Securing the API: article 32 in integrator’s language

Article 32 of the GDPR requires security measures appropriate to the risk. For a sending API, this translates into a handful of concrete practices.

The API key is an authentication secret, not a configuration value. It has no place in a Git repository, in a versioned configuration file, or in front-end code. It lives in a secrets manager or a server environment variable, and nowhere else.

Key rotation is the most neglected point. Many integrations have been running for years with the key generated on day one, known to three successive contractors and a former developer. Plan periodic rotation and immediate revocation at every departure or end of assignment. A platform that only allows one key per account condemns you to a service interruption at every rotation, which guarantees that nobody will ever do it.

Separation of rights comes next. A key dedicated to transactional sending does not need to be able to export the contact database. When the platform offers granular permissions or restrictions by IP address range, use them.

The OWASP API Security Top 10, in its 2023 edition, ranks broken object level authorisation as the top risk: the flaw that allows access to another account’s data simply by changing an identifier in the request. Broken authentication comes second. Two categories directly applicable to an API that handles contact lists.

The personal data security guide published by the CNIL, the French data protection authority, in its 2024 edition, covers these subjects with operational recommendations useful to French technical teams.

Then there is the authentication of the sends themselves. Going through an API does not exempt you from configuring your DNS records correctly. Setting up SPF, DKIM and DMARC to authenticate your sends remains the condition for reaching the inbox, whatever the triggering mode.

Finally, a scenario to prepare for before it happens: a compromised key that allowed your database to be exported constitutes a personal data breach. Article 33 requires notifying the CNIL within 72 hours of becoming aware of it, as soon as a risk exists for the data subjects. Knowing who calls, who decides and on what evidence is something you prepare in advance.

Your API provider is a processor, with the contract that goes with it

Article 28 of the GDPR governs the relationship between controller and processor. It must be the subject of a written contract, often called a DPA. This document almost always exists at serious vendors. It is almost always signed without being read.

Four points deserve a careful read.

The list of sub-processors, first. Your emailing provider itself relies on a hosting provider, sometimes on a bounce detection service, sometimes on a third-party SMS router. This chain must be documented and you must be informed of changes to it.

The actual location of processing, next. A French head office does not guarantee European servers. Check where the data is stored, where backups are replicated, and from which country technical support accesses customer accounts. An unregulated transfer outside the EU is a non-compliance, even if the interface is in French.

The retention periods applied by the platform, then. The CNIL recommends keeping the data of a non-customer prospect for three years from the last contact originating from them. If your platform keeps deleted contacts indefinitely in a technical recycle bin, you inherit the problem.

The terms of return and deletion at the end of the contract, finally. Export format, timeframe, proof of effective deletion.

At Ediware, these questions are handled by design: hosting in France, a documented processing chain and detailed contractual commitments on Ediware data security. Our Ediware API and integrations let you connect your CRM or ERP while keeping consent traceability on the platform side.

The mistakes that come up most often

None of these fixes requires a major project. They are integration decisions, taken once, that cost half a day at design time and much more once ten thousand daily sends are running in production.

Frequently asked questions

Is an emailing API provider automatically my processor?

Yes, as soon as it processes personal data on your behalf and according to your instructions. You remain the controller since you decide the purposes and the recipients. This relationship requires a written contract compliant with article 28 of the GDPR, generally provided in the form of a DPA by the vendor.

Is consent required to send a B2B email via API?

Not necessarily. Article L.34-5 of the Code des postes et des communications électroniques allows prospecting to a personal professional address without prior consent, provided that the subject of the message relates to the recipient’s professional activity and that a simple and free means of objection appears in every send.

How do you prove consent transmitted through an API call?

By making the proof travel with the data. Add the source of the consent, its timestamp and a reference to the original record to the payload, then store these attributes on the platform side. Without that, the proof stays in a single system and becomes hard to reconstruct after the record is modified.

Are transactional emails excluded from the scope of the GDPR?

No. The GDPR applies to any processing of personal data, transactional included. The distinction concerns the legal basis and the prospecting rules: a message strictly tied to the performance of a contract is not prospecting, but remains subject to the security, minimisation and information obligations.

How long should the call logs of a sending API be kept?

The GDPR sets no numerical duration; it requires you to define one and justify it in light of the purpose. For technical operating logs, a few months are generally enough. Beyond that, truncate the payloads to keep only the necessary metadata and purge the rest automatically.

What should you do if an API key is compromised?

Revoke the key immediately, generate a new one and analyse the access logs to measure the extent of the exposure. If personal data may have been viewed or exfiltrated, the CNIL must be notified within 72 hours of becoming aware of it, in accordance with article 33 of the GDPR.

Is hosting in France enough to make my integration compliant?

No. Server location eliminates the question of transfers outside the European Union, which is decisive, but it covers neither the legal basis of the sends, nor the minimisation of the data transmitted, nor the security of the access keys. The compliance of an API integration is decided across the entire chain.