An opt-out is not a checkbox in one tool. It is a fact about a person that has to reach every system capable of contacting them, and in a stack built on Apollo, Clay and HubSpot that is at least three separate copies of that person plus whatever sits downstream. The question the engines keep fanning out on this topic is how to sync the opt-out automatically. The honest answer is that there is no single switch, because the three products are built on three different assumptions: HubSpot treats opt-out as a status on a record it owns, Apollo treats it as a fact about its own database that you are then responsible for acting on, and Clay treats it as a filter you have to build into your own workflow.
Make HubSpot the system of record for opt-out, write every opt-out there first through the subscription preferences API, and make Clay and Apollo read from it rather than hold their own version. Then run Apollo's removal requests list on a recurring schedule, because that is the one signal that only exists on Apollo's side.
The failure mode is not a missing integration. It is two systems that each believe they are the source of truth, so a person suppressed in one gets re-enriched or re-pushed by the other. Decide which system owns the answer before you build anything, and the rest is plumbing.
What does GDPR actually require when someone opts out?
It requires you to stop, with no balancing test and no grace period, for direct marketing specifically.
Article 21 of the GDPR separates two different objections. Paragraph 1 covers processing based on legitimate interests or public task, and there you may continue if you can demonstrate compelling legitimate grounds that override the person's interests. Paragraph 2 covers direct marketing, and paragraph 3 is unambiguous about what follows: where the data subject objects to processing for direct marketing purposes, the personal data shall no longer be processed for such purposes. There is no override clause attached to it.
Two more parts of the same article shape the build. Paragraph 4 says the right has to be brought to the person's attention at the latest at the time of the first communication, presented clearly and separately from other information, which is why an unsubscribe link belongs in the first cold email rather than the fourth. Paragraph 5 says the person may exercise the right by automated means using technical specifications, which is the footing for a one-click unsubscribe rather than a reply-and-ask process.
What this means operationally is narrower than most teams assume. Objecting to direct marketing does not automatically require you to erase the record. In many cases the opposite is true: you need to keep enough of the person's identity to make sure you never contact them again, which is a suppression record, not a deletion. Erasure is a separate request with a separate workflow, and conflating the two is how teams end up deleting the only evidence that someone opted out.
Which system should hold the opt-out record?
Pick the CRM, and pick it explicitly, because the alternative is three partial answers.
HubSpot is the right holder in this stack for a structural reason rather than a product-preference one: it is the only one of the three that stores opt-out as a first-class status with a legal basis attached, and the only one with an API designed to be written to by other systems. HubSpot's subscription preferences API guide states plainly that subscription types represent the lawful basis to communicate with your contacts through email, and that the v4 endpoints let you programmatically subscribe or unsubscribe contacts from subscription types, or unsubscribe a contact from all email communication.
Apollo is explicit that it is not the holder. Apollo's removal requests documentation, updated 23 September 2026, states that because you are an independent controller of data you previously accessed from Apollo, Apollo does not automatically remove those individuals from your saved records, and that they may still exist in your contacts, sequences, CRM, integrations or other downstream apps. Clay is equally explicit. Clay's Do Not Contact compliance guidance tells customers to coordinate opt-out data from sales engagement tools, CRM or internal databases back into Clay so all downstream enrichments and workflows respect opt-out preferences, and suggests storing the complete list of opted-out contacts in either your CRM or a Clay table and running a lookup against it in every future prospecting workflow.
Both vendors describe the same architecture from their own side: one list, held somewhere you control, consulted by everything else. In a three-system opt-out build the first decision to write down is which system that is, and the second is the matching key, because an opt-out that cannot be matched will be ignored.
How do you capture an opt-out in HubSpot so it holds?
Turn on data privacy settings first, then record the status and the legal basis together, because one without the other is not an audit trail.
HubSpot's data privacy settings documentation, last updated 19 October 2026, describes what turning the setting on changes: the cookie consent banner is turned on, scheduling pages gain data privacy messaging, newly created forms include a data privacy section, and unsubscribe links are turned on for one-to-one and sequence emails for users who do not already have them. The same page describes a second toggle worth more than the first for outbound teams, under recommended next steps: limit emails to contacts with a subscription. There is also a consequence that catches people out, documented on the same page: one-to-one email opens and clicks are not tracked for contacts with no value for the legal basis for processing property. Accounts whose data storage is based in the EU have data privacy settings on by default.
The legal basis itself is a contact property. HubSpot's documentation on tracking legal basis, last updated 28 September 2026, lists six default options: three flavours of legitimate interest for leads, customers and other situations, performance of a contract, freely given consent, and not applicable. It also lists where the basis can be set, and that list is longer than most teams realise: list import, contact creation, a one-time basis on a single email, bulk edit, removing an opt-out status, resubscribing, and updating a contact in a workflow.
Keep erasure requests on their own track. HubSpot's data privacy request documentation, last updated 11 September 2026, covers a configurable request page with separate toggles for delete contact data and export contact data, a request manager where requests are assigned to a Super Admin, and three request types: data deletion, data export and enriched data deletion. Requests arriving by phone or in person can be created manually there, which matters because the pattern we see is that most opt-outs arrive as a reply to an email rather than through a form.
How do you push an opt-out into HubSpot from another system?
Through the v4 subscription endpoints, and the request body is the part to get right.
HubSpot's API guide for communication preferences documents the shape. A GET to /communication-preferences/v4/definitions returns every subscription type in the account with its internal ID, which you need before you can set anything. A GET to /communication-preferences/v4/statuses/{subscriberIdString}?channel=EMAIL, where the identifier is the contact's email address, returns the current status of each subscription for that person, as SUBSCRIBED, UNSUBSCRIBED or NOT_SPECIFIED.
Writing is two different calls depending on scope. A POST to /communication-preferences/v4/statuses/{subscriberIdString} updates one subscription type, and the body carries subscriptionId, statusState, legalBasis, legalBasisExplanation and channel. The guide is explicit that with data privacy settings turned on, the legalBasis field is required along with legalBasisExplanation. A POST to /communications-preferences/v4/statuses/{subscriberIdString}/unsubscribe-all opts the person out of every subscription type in the account, which is the call that corresponds to an Article 21 direct-marketing objection rather than to a preference change.
Reading back at scale is a plan question. The guide notes that the batch endpoints require a Marketing Hub Enterprise subscription to authorise the communication_preferences.statuses.batch.read and .batch.write scopes, so a team below that tier reconciles one address at a time or works from lists in the user interface instead. That constraint belongs in the design review rather than in the sprint where someone discovers it.
What does Apollo do when someone opts out, and what does it not do?
It removes them from its own database and flags them to you. It does not clean your workspace, and it does not clean your CRM.
Apollo's GDPR settings documentation, updated 6 October 2026, describes three workspace toggles under Settings, Outbound, Prospecting configuration: forbid prospecting of residents of the European Union, forbid email sending to residents of the European Union, and forbid tracking on emails sent to residents of the European Union. The third leaves sending intact and suppresses open and click tracking pixels. All three come with a caveat the page states directly: the settings only apply when Apollo can determine a prospect's location, and if the location cannot be resolved the settings cannot be applied. That is a meaningful gap, and it argues for a location-based filter in your own workflow rather than relying on the toggle alone.
The removal requests mechanism is the piece most teams miss. Apollo's removal requests documentation describes a dedicated list under Settings, Removal requests, available to admins, showing a rolling thirty-day view of people whose data your account accessed through saved contacts, CSV enrichment, the Apollo API or MCP, and who later asked to be removed from the Apollo database. The page recommends exporting that list roughly every thirty days as part of normal data hygiene, and says the list is provided solely to identify and honour deletion requests and must not be used for prospecting or enrichment.
Two practical limits on that list are documented and both affect matching. First, the records are deliberately incomplete: when someone requests removal, Apollo deletes their profile and retains only the minimum needed to honour the request, so entries carry limited details such as date removed, email address, professional social media, jurisdiction and contact ID. Second, the rolling window means that if nobody pulls the export for a couple of months, the requests from the first of those months are simply gone from the view. The page also notes that saved contacts who requested removal carry a banner on their profile, but that this banner only reflects saved contacts, so data that reached you through CSV enrichment or the API needs the list instead.
Apollo's own guidance on what to do next belongs in your runbook verbatim: if you no longer have an independent legal basis to retain or contact the individual, delete the contact from your workspace, and identify downstream records created or updated through CRM syncs, enrichment, imports or API workflows and remedy them.
How do you stop Clay from re-enriching someone who opted out?
With a lookup and a run condition, because Clay will not infer it.
Clay's Do Not Contact guidance sets out the pattern directly. Store the complete list of opted-out contacts in either your CRM or a Clay table, then use a lookup action in all future prospecting workflows to avoid re-enriching or engaging those contacts. The same page lists three controls that make this enforceable: people search filters that include or exclude countries and regions and can also exclude a company-maintained list, selective CRM uploads, and conditional logic. On the conditional logic point the page is specific, and this is the mechanism that does the real work: all actions in Clay carry the same only-run-if setting, which allows building logical flows to implement compliance procedures, so you can add a check before you sync data back to the CRM.
The selective-upload point is easy to misread, so take it the way Clay states it. When you source contacts through Clay, the data is not automatically synced to your CRM; you add an explicit action to create or update the record. That is a safety property, not a limitation. The suppression check belongs on that write action, where it is cheap and absolute, rather than upstream where a row can slip past.
Clay's HubSpot integration documentation supplies the pieces. The look up object action takes an object type and one or more fields to filter by, with HubSpot Object ID at the top of the list as the most precise match available, an AND or OR search operator once you filter on two or more fields, and a result limit that defaults to ten and tops out at two hundred. The update object action requires the HubSpot Object ID and carries an ignore blank values setting that is on by default, so blank values coming from Clay are left alone in HubSpot unless you deliberately turn it off. That default is the right one for a suppression workflow: an enrichment that returns nothing should never overwrite a populated field.
One scope detail decides whether any of this is possible on your plan. The integration's required scopes include read access to contacts, companies and leads, while write access to contacts and companies is an optional scope that is enabled by default, and the sequence scopes are off until you reconnect and enable them. If your workspace connected HubSpot with a reduced scope set, the write action that carries your suppression flag will not be available, and the fix is a reconnection rather than a workaround.
Where does the three-system sync actually break?
In the push direction, in the match, and in the gap between an opt-out and a deletion.
The push direction is the first trap. Apollo's HubSpot sync settings documentation, updated 22 October 2026, states that HubSpot push settings only affect net new contacts saved in Apollo or imported from a CSV, and that Apollo pushes updates to existing contacts automatically regardless of push settings. It also documents that when you push a net new contact whose associated account is not already in HubSpot, Apollo pushes the account too, which overrides your account push settings and can create companies in HubSpot even when account push is disabled. A suppression design that assumes push conditions gate everything will be wrong about both of those.
The match is the second trap, and Apollo documents the worst case itself: if a contact matches multiple existing accounts in HubSpot, Apollo randomly chooses which account to sync the contact to. Combine that with a removal request record that carries only partial details and you have two independent sources of ambiguity in the same pipeline. The pattern we see is that teams solve this by refusing to match on anything softer than an email address for suppression purposes, and by treating a near match as a flag for human review rather than as an automatic action.
The third trap is the one with the legal edge on it. Apollo's sync settings include a contact deletion sync option which, when enabled, deletes Apollo records linked to deleted HubSpot records and the reverse. That is useful for duplicate cleanup and dangerous for compliance, because if your opt-out process deletes the HubSpot contact, deletion sync can remove the Apollo-side record too, and you have now destroyed both copies of the evidence that the person asked not to be contacted. Suppress first, keep the suppression record, and handle erasure as a separate, deliberate action through HubSpot's data request manager when the person actually asks for erasure rather than objection.
What should the runbook contain?
Six things, and they fit on one page.
The ownership statement: HubSpot holds opt-out, with subscription status and the legal basis property as the two fields that constitute the record. The write path: the v4 subscription endpoints with a legal basis and explanation on every call, so no route into the record leaves the basis blank. The Clay gate: a lookup against the suppression list wired into the only-run-if condition of every enrichment and every CRM write. The Apollo schedule: the removal requests export pulled inside the rolling thirty-day window, matched on email, with unmatched rows queued for review rather than discarded.
The fifth is the separation of suppression from erasure, written down, because this is where good intentions do the most damage. The sixth is the location question Apollo's own documentation raises: the GDPR toggles apply only when a prospect's location can be resolved, so your workflow needs its own geography filter for the rest.
One gap to name plainly. Apollo's unsubscribe link article and HubSpot's permanent-delete article could not be read for this piece, so nothing here states what they say: the unsubscribe requirement comes from Apollo's GDPR settings page and the restorable and permanent delete options from HubSpot's data privacy settings page, both of which state them directly. Clay's DNC page carries a last-updated stamp of February 2025, older than every other source here, so treat its partner and registry details as the ones most likely to have moved.
FAQ
Does an opt-out in HubSpot automatically suppress the person in Apollo?
No. Apollo's removal requests documentation states that you are an independent controller of data you accessed from Apollo and that Apollo does not automatically remove individuals from your saved records. The sync that exists between the two products moves contact and account data, not suppression intent, so the suppression has to be built as its own path.
Which HubSpot API call corresponds to a GDPR direct-marketing objection?
The unsubscribe-all call. HubSpot's API guide documents a POST to /communications-preferences/v4/statuses/{subscriberIdString}/unsubscribe-all, which unsubscribes the contact from all email communication in the account. A per-subscription POST to /communication-preferences/v4/statuses/{subscriberIdString} is a preference change rather than a blanket objection, and the two should not be used interchangeably.
Do I have to delete someone who objects to marketing?
Not under Article 21 by itself. Paragraph 3 requires that the data no longer be processed for direct marketing purposes, which a suppression record satisfies while also making it possible to honour the objection in future. Erasure is a separate right with a separate request path, which in HubSpot runs through the data request manager.
How often should the Apollo removal requests list be pulled?
Apollo recommends roughly every thirty days, as part of a normal data hygiene process, which matches the rolling thirty-day window the list covers. Anything slower and entries age out of the view before anyone sees them.
How do I stop Clay spending credits on contacts who opted out?
Put the check on the run condition rather than after the enrichment. Clay's guidance is to hold the opted-out list in the CRM or a Clay table and run a lookup in every future prospecting workflow, and every Clay action carries an only-run-if setting that can gate on the lookup result before the enrichment fires.
Can Apollo create HubSpot companies even when account push is turned off?
Yes. Apollo's sync settings documentation states that pushing a net new contact also pushes the associated account if it is not already in HubSpot, which overrides your account push settings. Any suppression logic that lives only on the account push path will be bypassed by a contact push.
What legal basis value should an unsubscribe write carry?
Whatever is true, recorded with an explanation. HubSpot's legal basis property offers three legitimate-interest variants, performance of a contract, freely given consent and not applicable, and the subscription API requires both legalBasis and legalBasisExplanation when data privacy settings are on. The explanation is the field that makes the record defensible later, so it should say what happened rather than repeat the basis.
Where this leaves the build
This keeps being asked as "how do I sync GDPR opt-outs automatically" because it sounds like an integration problem. It is a data ownership problem in an integration costume. Once HubSpot is named as the holder, the Apollo side reduces to a scheduled export and a matching rule, and the Clay side to a lookup in a run condition. Neither is hard. What is hard is never letting a second system write its own answer to the same question.
Our Clay practice builds these gates into the workflow rather than bolting them on afterwards, which is the only version that survives contact with a busy outbound team.