The EU's Booking.com investigation raises an uncomfortable question for any business with partner integrations: can you say exactly what customer information each partner receives?
An integration can work exactly as intended and still share more information than it should.
Take a delivery partner. It needs a name, an address and enough order details to make the delivery. But an API may return the whole customer object because that is what the endpoint already provides. The extra fields do not stop the shipment. They may not trigger an error. They just leave the system alongside the information the partner actually needs.
This becomes a harder problem when the company has dozens of partners, older interfaces and more than one way of exporting data.
On 21 October 2026, the European Commission opened formal proceedings to examine whether Booking.com had adequately assessed and reduced certain risks under the Digital Services Act (DSA). The proceedings cover fraudulent accommodation listings, phishing risks connected to reservation and guest data shared with accommodation providers and messaging, and transparency around boosted listings. The Commission has opened an investigation; it has not established that Booking.com broke the law or confirmed a particular data breach.
Read the European Commission's announcement.
For a CTO or platform owner, the wider lesson is practical. A hotel needs reservation details. A healthcare billing provider needs defined patient information. A school platform exchanges student records with other systems. A merchant platform sends events to outside partners. The question is whether those partners receive only what their task requires, and whether the business can account for that access later.
The risk often starts with an extra field
The problem is not always a dramatic intrusion. Sometimes the receiving system is legitimate, the API key is valid and the response is successful. The unnecessary data is in the response itself.
That is close to what OWASP calls broken object property-level authorization. An API may protect the endpoint while still returning properties a particular consumer should never receive. OWASP recommends controlling which object properties are exposed rather than serializing everything by default. See OWASP API Security Top 10: API3:2023.
There are legal and operational dimensions too. Where the GDPR applies, its data-minimization principle requires personal data to be limited to what is necessary for the purpose. That is a separate legal point from the Booking.com investigation under the DSA. Read GDPR Article 5.
For the business, broad data sharing makes an incident harder to assess. If a partner account is compromised, the response team has to work out not only which integrations were active, but which fields were available, for which customers and over what period. If nobody recorded the answer, engineers end up reconstructing it from old payloads, application logs and assumptions.
What a controlled integration looks like
The following comparison is a design checklist, not a description of Booking.com's systems or a claim that every company currently takes these shortcuts.
- Payload. Shortcut: send the full customer or order object. Better: define a field allowlist for each partner and purpose. Why it matters: fewer unnecessary disclosures to investigate.
- Partner access. Shortcut: reuse a broadly privileged credential. Better: scope credentials, tenants and operations to the partner's role. Why it matters: a compromised account has a narrower reach.
- Evidence. Shortcut: log that an API request succeeded. Better: record the recipient, time, data category or schema version, and correlation ID. Why it matters: the team can reconstruct what was shared without storing a second copy of the data.
- Offboarding. Shortcut: remove the integration in a later development sprint. Better: revoke credentials and pause exports, queues and webhooks through an established procedure. Why it matters: the business can stop new transfers promptly.
- Data already sent. Shortcut: assume revoking the API key resolves the issue. Better: maintain retention, deletion and incident-notification obligations with the provider. Why it matters: copies held by the partner are still accounted for.
The last point matters. Revoking access stops future transfers; it does not pull back information the partner already received. Contracts, retention controls and incident procedures have to cover that part of the problem.
Four questions worth asking before launch
What exactly does the partner need?
Ask the person who owns the workflow, not only the engineer implementing the API. A delivery company might need an address and delivery instructions. A verification provider may need a different, tightly defined set of data.
Write those fields down. Make the list part of the integration contract and enforce it in the code. Then test what happens when someone adds a new property to the internal customer model. It should not appear in an external response by accident.
Can we trace a disclosure without creating another sensitive-data store?
A useful record can identify the partner, event, timestamp, outcome, approved data category or schema version, and a request correlation ID. The exact content depends on the workflow and applicable requirements.
Avoid copying entire personal-data payloads into routine logs. Logging the customer record to prove you shared it simply creates another copy to secure and retain.
The test is whether someone can answer: Which partners received this customer's information last March? If the answer depends on finding a developer who remembers an old integration, the audit trail needs work.
What happens if the partner's credentials are stolen?
The receiving organization may be trusted while an individual account is not. Restrict partner credentials to the functions and tenants they need. Protect partner administration with appropriate authentication, and establish a separate way to verify sensitive changes such as new payment instructions.
Limiting fields reduces exposure. It does not prevent every scam conducted through a compromised account or a convincing message sent from a familiar system.
Can we stop the flow without breaking everyone else's?
Test revocation before it becomes an emergency. In a controlled environment, disable one partner's credentials and outgoing events. Check queued messages and scheduled exports as well as synchronous API calls. Confirm other partners continue to receive their data.
That exercise often reveals work that a successful API test misses: shared credentials, exports nobody owns, or a queue that keeps retrying after access should have been removed.
The business questions behind the security controls
You do not need to invent a risk score to find out whether the integration is manageable. Start with four measures that have operational meaning:
- Coverage: How many production partners have a documented owner and approved field-level data contract?
- Traceability: Can support and security identify recipients and data categories for a specific customer and period?
- Revocation time: How long does it actually take to stop new transfers to one partner in a controlled test?
- Offboarding: Can the organization establish what a former provider may still hold and which deletion obligations apply?
The numbers should come from the company's own systems. There is no useful universal target for every platform, and a theoretical runbook is not the same as a tested procedure.
A product leader can use these answers to prioritize engineering work. A security team can use them to scope an incident. A legal or compliance team can establish which partners need to be contacted. This is where an architecture decision becomes a business capability.
Where VARTEQ's project experience fits
On the NORTH merchant and partner platform, VARTEQ worked on an AWS-based, event-driven partner-notification pipeline. The implementation processed partner destinations independently, so an unavailable endpoint would not hold up notifications for the others. Notification delivery attempts were also recorded in an audit history.
Read the NORTH merchant and partner platform case study.
Those are useful examples of delivery isolation and notification traceability. They do not establish that NORTH has a full personal-data disclosure register, implements every control discussed here, or has any specific regulatory certification. The distinction is important: knowing a message was delivered is different from knowing every personal-data field that left the system.
For an organization building a new partner connection, these issues belong in the scope of API integration. For teams working with older systems, some may need to be addressed as part of application modernization.
A related but separate problem is unreliable delivery: retries, duplicate webhooks and mismatched states. We cover that in Why fintech integrations fail in production. Data-sharing controls and delivery reliability need different tests.
A useful check for this week
Pick one integration that matters to the business. Ask to see the actual outbound payload, not the intended schema in a ticket. Compare it with what the partner needs. Then ask for a record of what was sent to that partner on a specific date and rehearse disabling future access in staging.
You may find the integration is already well controlled. Or you may find a full customer object in a webhook that only needs three fields. Either result is more useful than another policy statement.
Working on a new partner connection or untangling an inherited one? Talk to VARTEQ about the integration and the data flowing through it. We can discuss the engineering scope and a practical starting point.
Frequently asked questions
What is the European Commission investigating about Booking.com?
On 21 October 2026, the Commission opened DSA proceedings covering fraudulent accommodation listings, phishing risks related to reservation and guest information, and transparency around boosted listings. The investigation is not a finding of wrongdoing or confirmation of a particular breach.
What should a third-party data-sharing log record?
Enough to identify who received information, when, for which business event, and which approved category or schema of data was involved. Use event IDs and correlation references rather than storing full customer payloads in routine logs.
Can a company revoke customer data already shared with a partner?
It can stop future access and transfers by revoking credentials and disabling exports or events. Data already copied by the partner cannot be technically recalled that way. Retention, deletion and incident-response arrangements must address existing copies.
