DPDP Act29 May 2026 8 min read

DPDP Act API Data Sharing: B2B Data Flow Compliance

How the DPDP Act 2023 applies to API-based personal data sharing between businesses — what contracts are needed, how to classify the relationship, and technical controls.

Key Takeaways

API-based personal data flows are subject to the DPDP Act — whether the receiving party is a Data Processor or a separate Data Fiduciary determines the contract structure required.
When an API customer receives personal data and uses it for their own purposes, they become a Data Fiduciary and the data sharing requires the original Fiduciary's users' consent.
API terms of service must include DPDP Act-compliant DPA provisions for API customers who process personal data.
Technical controls — rate limiting, field-level access controls, audit logging — are both security measures and compliance evidence.
AA (Account Aggregator) framework provides a DPDP-aligned model for regulated financial data sharing between Indian entities.

In this guide

API Data Sharing and the DPDP Act
When API Customers Are Fiduciaries vs. Processors
DPDP Requirements in API Terms of Service
Technical Access Controls for Personal Data APIs
Obtaining Consent for Third-Party Data Sharing
The Account Aggregator Framework
Monitoring API Usage for Compliance

Modern SaaS architectures are built on APIs — products consume data from third-party APIs, expose their own APIs to enterprise customers and integration partners, and participate in ecosystems where data flows between multiple services. When personal data is part of these API flows, the DPDP Act applies with the same force as any other data processing activity. The technical mechanism (API vs. file transfer vs. batch export) does not change the legal analysis.

Indian B2B SaaS companies often build platform businesses where their API exposes customer or user data to third-party developers, enterprise integrations, or partner applications. Each of these API access patterns must be assessed against the DPDP Act: what personal data is accessible via the API? Who is accessing it? For what purpose? On what lawful basis? What protections are in place?

API data sharing is also a significant risk vector for DPDP Act breaches. An API that exposes personal data without adequate access controls, authentication, or audit logging is both a security vulnerability and a DPDP compliance failure. The integration between security controls and DPDP compliance is particularly tight in API architectures.

When API Customers Are Fiduciaries vs. Processors

The most important question in API data sharing is whether the entity receiving personal data via the API is acting as a Data Processor (processing data on your behalf and under your instructions) or as a separate Data Fiduciary (receiving data and using it for their own purposes). This classification determines the contract structure and the consent requirements.

An integration partner who connects your product to their workflow automation tool, using the API to sync data within their own organisation, is likely a Data Processor — they receive the data to fulfil a specific integration task at the instruction of the shared customer. A third-party developer who builds an app on your API platform and uses user data to provide their own independent service is a Data Fiduciary — they determine the purpose and means of using that data independently.

When an API recipient becomes a separate Data Fiduciary, the data sharing is a transfer between Fiduciaries. The original Fiduciary must have a lawful basis for the sharing — typically, disclosure in the privacy notice and consent from the Data Principal to sharing with the receiving Fiduciary. Simply providing API access does not create a valid basis for sharing; the original Data Principals whose data is shared must be aware of and have consented to the sharing.

DPDP Requirements in API Terms of Service

Your API Terms of Service (or Developer Agreement) must address DPDP Act requirements for API customers who access personal data. At minimum, include: (1) a representation that the API customer will use the API and personal data only for the purposes disclosed to Data Principals and with appropriate lawful basis; (2) DPDP-compliant DPA provisions (equivalent to those in your vendor DPAs) for API customers processing personal data as your Processor; (3) a prohibition on using personal data for the API customer's own purposes beyond what is authorised by the Data Fiduciary (you or your shared customer); (4) a breach notification obligation requiring the API customer to notify you of any security incident involving your users' data; (5) deletion obligations when API access is terminated.

Review your existing API terms against this checklist. Most standard API terms of service focus on rate limits, intellectual property, and acceptable use — they do not contain adequate personal data protection provisions. Add a DPDP Act-specific section or a separate DPA addendum for API customers who access personal data.

For enterprise API customers who have significant data access (e.g., full data export APIs, bulk user data access), consider requiring execution of a separate formal DPA rather than relying on click-through API terms. A signed DPA is stronger evidence of contractual data protection obligations and signals that you take the responsibilities seriously.

Technical Access Controls for Personal Data APIs

Implement the principle of least privilege at the API level: API clients should only have access to the personal data categories they need for their stated purpose. Use OAuth 2.0 scopes or equivalent permission structures to limit access to specific data types. An analytics integration should not have access to payment data; a CRM integration should not have access to medical records. Design scope granularity into your API from the outset.

Implement comprehensive API access logging: record every API call that returns personal data, including: the API client ID, the data categories accessed, the timestamp, and the volume of records. These logs serve dual purposes — security monitoring (detecting anomalous access patterns) and DPDP compliance evidence (proving what data was accessed by whom and when). Retain API access logs for a minimum of 3 years.

Apply rate limiting and throttling at the API level, not just for DDoS protection but to limit the volume of personal data that can be extracted by any single API client in a given period. Bulk data extraction via API is a common data exfiltration technique — rate limits constrain both malicious bulk extraction and excessive legitimate access that may exceed what was consented to.

When your product shares personal data with third-party applications via API — particularly when those applications are separate Data Fiduciaries — your privacy notice must disclose this sharing and your consent mechanism must obtain specific consent for it. "We may share your data with third-party applications" is not specific enough; users should be informed about the categories of third parties and the types of data shared.

For marketplace or platform models where users can connect third-party integrations (Zapier, Salesforce, Slack, etc.) to their account, implement an OAuth-style user authorisation flow: when a user connects an integration, explicitly show them what data the integration will access and obtain their specific consent to that sharing. This OAuth authorisation serves as the DPDP Act consent record for the sharing.

When users disconnect an integration, trigger deletion of personal data shared with the disconnected application. Your API terms should require integration partners to delete data upon disconnection. Build automated deletion triggers into your integration management system: on disconnection, invalidate the API token, and send a deletion notification to the integration partner.

The Account Aggregator Framework

India's Account Aggregator (AA) framework, regulated by the RBI, provides a DPDP Act-aligned architecture for sharing personal financial data between regulated entities. Under the AA framework, individuals consent to the sharing of their financial data from Financial Information Providers (banks, insurers) to Financial Information Users (lenders, advisors) through a licensed Account Aggregator as the consent manager.

The AA framework is a real-world implementation of the DPDP Act's consent-based data sharing model: explicit, granular, revocable consent; purpose limitation; time-limited access; and a trusted intermediary (the AA) to manage and record consent. Fintech companies building on the AA framework are effectively implementing DPDP principles in a regulated context.

The AA framework provides a template that other sectors may follow as India's data-sharing infrastructure matures. Healthcare data (under the ABDM — Ayushman Bharat Digital Mission) and other regulated data sharing contexts are building similar consent-based architectures. API-based data sharing in regulated industries should be designed to align with sector-specific consent frameworks as they emerge.

Monitoring API Usage for Compliance

Monitor API usage patterns to detect and respond to DPDP compliance issues. Set up alerts for: bulk data access by API clients (which may indicate data exfiltration or a scope violation), API access to data categories beyond the client's authorised scope, unusually high volumes of Data Principal rights requests coming via API (which may indicate a customer using your API to build a DSAR automation without your knowledge), and access from API clients with expired or revoked tokens.

Conduct periodic API access reviews: review the list of active API clients, confirm that each has a current and compliant DPA, verify that actual API access patterns match the declared purpose in the DPA, and confirm that dormant API clients (those with no recent access) are deprovoked. Token hygiene — removing unused API credentials — reduces the attack surface and simplifies your compliance footprint.

Include API data sharing in your annual DPDP compliance review. Review: whether all API clients have current DPAs, whether the data shared via API is covered by your privacy notice and consent flows, whether any new API integrations have been added without privacy review, and whether any API clients have experienced security incidents that should have triggered notification under the DPA.

Frequently Asked Questions

Do we need a DPA with every company that uses our public API?

For API clients who access personal data, yes — you need contractual data protection provisions. For a completely public API that provides only non-personal data (e.g., public transport schedules, weather data), no DPA is needed. For personal data APIs, at minimum embed DPA terms in your API Terms of Service. For enterprise clients with significant data access, execute a formal separate DPA.

One of our API integration partners had a security breach. Are we liable?

This depends on your contractual relationship and the role classification. If they were a Data Processor under a DPA, your liability turns on whether you performed adequate oversight and whether the DPA's security requirements were met. If they were a separate Data Fiduciary, the breach is primarily their liability. In either case, investigate whether your users' data was affected and assess whether you have any Board notification obligation.

We offer a bulk data export API that enterprise customers use to move data to their own systems. What does DPDP require?

Bulk data export is high-risk from a DPDP perspective because it involves mass transfer of personal data outside your control. Ensure: the enterprise customer has a valid reason for bulk export covered in your DPA; your privacy notice discloses that data may be exported at customer instruction; the export is authenticated and logged; the receiving system (the customer's) is covered by the DPA's security requirements; and the customer is responsible as Fiduciary for the exported data once it leaves your environment.

Does the DPDP Act require API rate limiting?

The Act does not specifically require rate limiting, but the Section 8(5) reasonable security safeguards obligation supports implementing controls to prevent bulk data extraction. Rate limiting that constrains the volume of personal data accessible per API call and per time period is a reasonable security control in an API context. It is also relevant to demonstrating that you have implemented controls to prevent unauthorised bulk access.

If we delete a user's data in response to an erasure request, must we also trigger deletion in all downstream systems that received data via our API?

Yes. An erasure request covers all systems you have provided data to — including API recipients who are your Data Processors. Your DPA with those processors should include an obligation to delete data upon your instruction, and your erasure workflow should trigger deletion instructions to all downstream Processors. For API recipients who are separate Fiduciaries, the legal analysis is more complex — they have their own retention obligations and erasure rights analysis.