As of March 1, 2025, the GDPR Enforcement Tracker recorded 2,245 fines with complete information, or 2,560 cases including records with limited information, a reminder that privacy compliance is an operating responsibility, not a policy-writing exercise. The CMS GDPR Enforcement Tracker puts real enforcement activity behind a familiar product moment.
A customer pastes a professional profile URL or company URL into a SaaS feature. A B2B data API returns structured JSON, and the product stores it, scores it, or shows it to a sales or recruiting user. If a returned record identifies a person, public availability doesn't take it outside privacy regulation.
Founders, product managers, and engineers adding enrichment or people and company data need a practical way to scope the work. The useful sequence is a comparison for the scoping meeting, a lawful-basis test for live public professional data, opt-out and deletion mechanics, and a role decision for the provider, customer, and downstream user.
Working rule: Public pages can reduce collection friction. They don't remove duties around purpose, accuracy, security, disclosure, or copies that outlive an API call.
Table of Contents
- Why Public Professional Data Still Needs a Program
- CCPA and GDPR Duties Compared for a SaaS API
- Lawful Basis for Live Public Profile Data
- Opt-Outs, Sensitive Limits, and Field Inventory
- How Deletion Moves Through the Enrichment Chain
- Processor, Controller, or Broker for Each Call
- Security, Breach Duties, and the Release Evidence Pack
Why Public Professional Data Still Needs a Program
The comparison below is a practical starting point for deciding which obligations apply before the team settles its data model or drafts a privacy notice.
CCPA and GDPR Duties Compared for a SaaS API
| Topic | GDPR | CCPA and CPRA |
|---|---|---|
| Who it can reach | Organizations processing personal data of people in the EEA, including non-EU SaaS vendors | For-profit businesses doing business in California that meet a threshold, even if not headquartered there |
| Threshold | No revenue or volume threshold | For 2025, gross revenue of at least $26.625 million, personal information of at least 100,000 California residents or households bought, sold, or shared, or at least 50% of annual revenue from selling or sharing that information |
| Core trigger | Documented lawful basis before processing, plus transparency | Notice at collection plus consumer rights, and an opt-out if the business sells or shares |
| Sensitive data | Special category data needs an additional condition | Right to limit use and disclosure of sensitive personal information |
| Sale or sharing | Onward disclosure still needs a basis and usually a contract | Opt out of sale and sharing for cross-context behavioral advertising |
| Individual rights | Access, rectification, erasure, restriction, portability, and objection | Know, delete, correct, opt out, limit sensitive personal information, and equal service |
| Response clock | Generally one month, with a possible two-month extension for complex requests when the person is told | Generally 45 days, with one 45-day extension if the person is notified |
| Penalty scale | Regulatory fines and corrective orders, including orders to erase data or restrict or ban processing | 2025 administrative fines up to $2,663 per violation and $7,988 for intentional violations or violations involving consumers known to be under 16; breach statutory damages of $107 to $799 per consumer per incident when actual damages aren't claimed |
California's 2025 thresholds are $26.625 million in annual gross revenue, personal information from at least 100,000 California residents or households bought, sold, or shared, or at least 50% of annual revenue from selling or sharing that information, according to the California privacy authority's monetary-threshold guidance. The thresholds matter even if a business isn't headquartered in California. The state's approach turns partly on business scale and data activity, while GDPR applicability doesn't depend on a revenue floor.
For an API product, the trigger difference matters. GDPR requires a lawful basis before processing and transparency about the processing. California's framework focuses on notice and consumer rights, with a right to opt out when a business sells or shares personal information. “Sharing” includes disclosure for cross-context behavioral advertising, so a team shouldn't assume that a transfer is irrelevant because no money changes hands.
The table also distinguishes the special conditions that apply to certain sensitive data under GDPR from California's right to limit use and disclosure of sensitive personal information. In practice, both regimes reward a field inventory that lets the product treat contact details, location, and other higher-risk attributes differently from ordinary professional information.
For a broader orientation to overlapping regulatory work, Freeform Company's overview of GDPR, HIPAA, CCPA, and SOX requirements can help a team identify where its privacy work intersects with other compliance obligations. It doesn't replace legal scoping for a particular product.
Before designing fields, mark which column applies based on your revenue, California data volume, and EEA users. Then use those answers to decide what the API returns, how rights requests will reach it, and which party owns each task.
Lawful Basis for Live Public Profile Data
A professional profile URL is a source, not a lawful basis. Under GDPR, manifestly public personal data may still require a documented legitimate-interest assessment under Article 6(1)(f). The European Data Protection Board's legitimate-interest guidelines call for examining the profile's detail and completeness, the effect on the person, possible future combination with other data, fairness, nondiscrimination, and accuracy safeguards.
The assessment should be tied to a use case, not filed away as a general statement that public information is useful. A customer and provider should be able to explain the purpose, why on-demand enrichment is necessary instead of keeping a standing warehouse, whose interests are being balanced, and which safeguards reduce the impact on the person.
A fresh read on each call can reduce reliance on stale records, but it doesn't transfer controller duties to the API. The controller may still need to provide information about the source under GDPR Article 14, generally within one month of obtaining data from a third party unless an exemption applies. Customers may also need to handle access and objection requests, provide notices, and establish whether the provider is acting as a processor, a controller, or an independent controller for the specific operation. For a related explanation of data sourcing, see first-party versus third-party data.
Make the assessment enforceable in the product
Separate ordinary professional attributes, such as role, employer, and skills, from higher-risk fields such as contact details, inferred attributes, and precise location. Then build the assessment into the API and surrounding product rather than leaving it as a legal document no engineer can apply.
- Use purpose-specific field allowlists. Make each feature request only the fields it needs. A role-matching feature shouldn't receive contact details by default.
- Preserve provenance. Attach source and retrieval-time metadata so teams can explain where a field came from and when it was obtained.
- Support suppression and correction. Keep a suppression path that prevents unwanted records from reappearing, and offer a clear route to correct disputed information.
- Set retention limits. Decide which records need to persist, where they persist, and how long each copy remains available.
- Log the decision. Record the input URL, retrieval time, fields returned, customer identity, legal-purpose tag, and downstream disclosure.
A live-fetch architecture can reduce stale-data risk, but it doesn't erase the need for controls. The European Data Protection Board's guidance supports assessing the specific use and safeguards rather than treating public availability as a blanket permission.
The practical test is simple: if the team can't name the purpose and the fields it refuses to return, the lawful basis is being asserted, not demonstrated.
A short video can help teams orient themselves to the legal-basis question before reviewing their own use case.
Opt-Outs, Sensitive Limits, and Field Inventory
A privacy notice can describe an opt-out, but the product has to enforce it. California guidance requires a clear and conspicuous “Do Not Sell or Share My Personal Information” link and at least two ways for consumers to submit an opt-out request when a business sells or shares personal information. A browser or device-based signal such as Global Privacy Control can also communicate the request automatically. The California Attorney General's CCPA guidance explains that the business generally must stop selling or sharing that person's information unless the person later authorizes it again, and must wait at least 12 months before asking them to opt back in.
Check before building the response
The suppression check belongs before JSON generation, not after the product has written a response into a warehouse. Match identifiers that can connect a person across customers or be reused for cross-context advertising. Don't make the consumer create an account just to have an opt-out signal applied.
For every returned field, keep an inventory entry with its purpose, source record, retention rule, and deletion behavior. Make the behavior explicit: does a deletion request erase the data, add a suppression record to prevent it returning, or require both? That distinction matters when the source remains publicly available but the product must stop providing the information.
Separate ordinary profile attributes from sensitive personal information so a limit-use request can remove restricted fields without blanking a whole response unnecessarily. Apply equal-service principles too: an opt-out shouldn't degrade the product beyond what's necessary when particular data is no longer available. For practical examples of how teams identify personal information, use Vigil Security's PII learning objectives and examples.
Contracts need to make the data path enforceable. Specify when the customer is a service provider or contractor, prohibit using information outside the instructed purpose, restrict unauthorized combination and onward sale, require reasonable security, and assign responsibility for verifying consumer requests. The API documentation should state data categories, request channels, verification steps, and escalation timing rather than sending customers to a generic privacy page. Teams planning a people-data feature can also review this people data API overview.
Before release, run a test profile that has opted out. The response should contain no blocked fields, and the system should generate no sale or sharing event for that profile.
How Deletion Moves Through the Enrichment Chain
Deletion fails when a provider removes its copy but a customer cache, export, log, model feature, or later fetch puts the person back into the workflow. California's DROP mechanism is designed to let one verifiable request reach every registered data broker. Under the California Privacy Protection Agency's Delete Act update, beginning August 1, 2026, registered brokers must check DROP at least every 45 days, delete matched personal information and inferences unless an exemption applies, report status within 45 days, and maintain suppression records so the data doesn't reappear.
Build the deletion path as a sequence with an owner for every handoff:
- Verify and resolve identity. Confirm the requester through the appropriate process, then identify the person using a stable identity key rather than relying only on the last URL submitted.
- Fan out the request. Send it through live retrieval, short-lived caches, asynchronous jobs, customer exports, backups, and derived inferences. Write down any exceptions and who approves them.
- Suppress first. Create the suppression record before deletion finishes, so a new extraction can't repopulate the person while other systems are still processing the request.
- Notify customers holding copies. Identify downstream customers that store a response, give them a clear action and deadline, and capture confirmation.
- Keep evidence. Record what was deleted, what was retained under an exemption, and when the person or requesting system received an update.
GDPR rights need to reach the same stores. Erasure and objection requests can't stop at the API boundary when customers keep a response or create a derived feature. A live retrieval design can reduce persistent provider-side storage, but customer systems still need a defined route to update or remove their copies.
Retention rules should reflect the actual purpose. Choose short cache time-to-live settings measured in hours when the product only needs temporary reuse, limit request logs to the details security needs, and retain suppression tombstones longer than the profile itself when needed to prevent re-import. The policy should say where backups fit and whether a deletion request removes data immediately or at the next documented backup cycle.
Run a verification drill: submit a test deletion, call the same professional profile URL again, and confirm that the response stays suppressed. Then check a customer export and any derived feature. A successful provider-side deletion isn't enough if the person's data can still return through another system.
Processor, Controller, or Broker for Each Call
A public source doesn't choose the legal role. The deciding facts are who determines the purpose and means of processing, whose instructions govern the call, and what each party does with the response.
| Pattern | Usual role split | Extra duty to confirm |
|---|---|---|
| Customer enriches only its own users under written instructions | Customer is controller and the API vendor is processor | Processing addendum, purpose limit, and assistance with access and deletion |
| Customer submits a professional profile URL for a person with no direct relationship | Often independent controllers | Separate purpose, transparency, and a contract that doesn't pretend one notice covers both |
| Product derives scores or other attributes not on the source page | Inferences stay personal information for whoever creates them | Correction, deletion, and a ban on high-impact uses that weren't assessed |
| Provider licenses personal information about people it has no relationship with | Possible California data broker | Annual registration, or $200 per day if registration is missed, plus Delete Act checks |
| Live response with no provider-side profile store | Provider retention is low, but customer copies may still exist | Suppression at the customer cache, export, and model feature, not only at the API |
The second row deserves particular care. If a customer supplies a professional profile URL for someone who never signed up, the customer and provider may each have their own purposes and transparency responsibilities. A contract that calls the provider a processor doesn't settle the question if the provider determines its own use of the data.
Inferences also need a place in the data model. If a product derives a score or attribute, treat it as personal information for the party that creates it, and make sure correction and deletion workflows include the derived value. Don't let a field escape rights handling just because it wasn't copied directly from a source page.
California's data-broker definition creates a separate decision point. The California Privacy Protection Agency's enforcement announcement described a broker that amassed billions of public records, generated inferences about individuals, and was required to shut down operations through 2028 unless it paid a fine. Businesses that meet the data-broker definition must register annually, and failure to register can trigger administrative fines of $200 per day.
Apply the same decision tree to a real-time professional data API such as Fetchin, which returns live public profile and company data as JSON rather than serving a periodic snapshot. Fresh retrieval, field-level responses, and failed calls that don't consume credits may support accuracy and minimization, but they don't assign the legal role. The contract and actual conduct do.
Contract test: Label each endpoint and each customer tier with a role before the next security review. If the intended role doesn't match what the product does, fix the product or the agreement.
Security, Breach Duties, and the Release Evidence Pack
A privacy release should leave evidence that the system can enforce its choices. Scope API keys to the customer and feature that need them, protect traffic with TLS, encrypt caches and exports at rest, and restrict access to people who need it. Tag access logs with the same purpose code used in the audit trail so reviewers can connect each request to an approved use.
GDPR requires notifying the supervisory authority of a personal data breach within 72 hours of awareness. California Civil Code section 1798.150 provides for statutory damages of $107 to $799 per consumer per incident in qualifying cases. Define who triages an incident, who can disable an endpoint, and who communicates with customers. The guide to incident response roles and escalation guidance can help organize those responsibilities.
For EEA personal data sent to a US-hosted provider, name the transfer mechanism in the contract, such as the EU-US Data Privacy Framework or standard contractual clauses. The release evidence pack should include a purpose note for each feature, a field allowlist, an opt-out test showing no sale or sharing event, and a named owner for every request channel. Include a deletion test that confirms a deleted profile URL cannot be replayed from a cache or downstream customer copy.
That test is where public data creates a harder engineering problem than a notice checklist. A live API can return a fresh JSON read of a professional profile or company URL, but aggregation and reuse still require controls across caches and customer systems. Keep provenance discoverable with a maintained data provenance guide, and make the evidence show how privacy choices travel with the data.
Use Fetchin to retrieve live professional profile and company data as structured JSON for SaaS features that need current information. Before adding enrichment to production, define the lawful purpose, field limits, opt-out behavior, and deletion handoffs the product will enforce.
