API Development Services, security and the DPDP Act: a compliance checklist
Is API development services compliant with the DPDP Act?
No service is compliant in the abstract; your implementation either is or is not. An API handling personal data of people in India must carry a purpose with every read, restrict access by role, log who saw what, enforce retention automatically and delete on request. Those five controls belong in the specification.
No service is compliant in the abstract; your implementation either is or is not. An API handling the personal data of people in India has to carry a stated purpose with every read, restrict access by role, log who saw what, enforce retention automatically and delete on request. Those five controls belong in the specification rather than in a later hardening sprint.
This is a mapping exercise rather than a legal explainer. Each obligation is paired with the control that satisfies it at the API layer and the evidence an auditor will actually ask for, followed by the security work the Act assumes but does not describe.
What the DPDP Act requires of an API
India's Digital Personal Data Protection Act, 2023 governs the processing of digital personal data in India and processing outside India connected with offering goods or services to people in India. Its core duties fall on the data fiduciary, the entity deciding why and how data is processed, and that is you rather than your development partner. The Ministry of Electronics and Information Technology publishes the data protection framework and the rules made under the Act.
Five duties translate directly into API design decisions. Processing must have a lawful basis, usually consent recorded for a specific purpose. Data collected must be limited to what that purpose needs. It must be accurate and correctable. It must not be kept once the purpose is served. And the fiduciary must be able to demonstrate reasonable security safeguards and notify a breach. Every one of those has an engineering expression.
The part that catches teams out is that these are not features bolted onto an endpoint. Purpose and retention are properties of the data model, and erasure is a code path that must reach replicas, caches, search indexes, message queues and log sinks. Eazyware scopes API development and integrations with those properties written into the contract, because retro-fitting them into a live API is an order of magnitude more expensive than designing them in.
Obligations mapped to API controls
| DPDP obligation | The control at the API layer | Evidence an auditor accepts |
|---|---|---|
| Lawful basis and purpose | Every request carries a purpose claim; the service rejects reads with no valid purpose | Request logs showing purpose per call and a consent record per subject |
| Data minimisation | Field-level scopes; responses return only the fields the caller's scope permits | The OpenAPI document with per-scope response schemas and passing contract tests |
| Accuracy and correction | A documented update path plus propagation to downstream consumers | Correction request log with timestamps and downstream acknowledgements |
| Storage limitation | Retention periods on personal fields enforced by a scheduled job | Job run history showing records expired on schedule |
| Erasure on request | A delete path reaching primary store, replicas, caches, indexes and logs | A completed erasure trace across every system that held the record |
| Reasonable security safeguards | Authentication, role-based authorisation, encryption in transit and at rest, secret rotation | Access reviews, key rotation records and penetration test findings with fixes |
| Breach notification | Alerting on anomalous access volumes plus an incident runbook | Incident timeline showing detection, containment and notification |
The security work the Act assumes
Reasonable safeguards is a standard, not a specification, and regulators judge it against accepted practice. For APIs the accepted practice is well documented: the OWASP API Security project catalogues the failure classes that dominate real breaches, and broken object-level authorisation sits at the top of that list for a reason.
Authentication is the easy half
Use OAuth 2.0 with short-lived access tokens for user-facing flows and machine credentials with scoped permissions for service-to-service calls. Rotate secrets on a schedule and hold them in a managed secret store rather than in environment files. Long-lived static API keys shared between four partners are still the most common finding in an API review, and the mitigation is boring: issue one credential per consumer, log its use, and revoke without a deployment.
Authorisation is the half that fails
Authentication proves who is calling. Authorisation decides whether this caller may see this specific record, and it has to be enforced on every object, in the service, not in the client. An endpoint that returns any record whose identifier is supplied is the defect behind a large share of reported API breaches, and it passes every functional test because the tests use identifiers the caller owns. Check ownership server-side on each object and write a test that deliberately asks for someone else's. SSO, RBAC and audit logs covers the wider access model.
Abuse and exposure controls
Rate limit per credential rather than per IP address, because a partner behind a gateway shares one address. Cap page sizes so that a paginated endpoint cannot become a bulk export. Redact personal fields from application logs and from error traces, which is where personal data most often leaks without anyone deciding to expose it, and keep PII redaction in the logging layer rather than in each handler.
Residency and deployment
The Act does not impose blanket localisation on all personal data, but sector regulators do impose their own requirements, and contractual commitments to enterprise customers frequently go further than either. Reserve Bank of India expectations around outsourcing, audit access and where regulated data lives are the ones most likely to shape a fintech API, and they are covered in RBI guidelines, outsourcing and audit.
Practically, decide residency once and enforce it with infrastructure rather than policy. That means an Indian region for primary storage and backups where the obligation applies, a private network deployment so that no personal data traverses the public internet between services, service accounts scoped per integration, and an explicit list of third parties that receive any personal field. Data residency sets out the distinctions buyers most often blur, and the cost implications sit in API development services in India.
The checklist
Run this before the first endpoint is implemented, and again before go-live.
- Tag personal fields in the schema. If the data model does not know which columns are personal, nothing downstream can enforce anything.
- Attach a purpose to every read path. Reads without a declared purpose should fail rather than default to permitted.
- Enforce object-level authorisation server-side, with a negative test that requests another tenant's record and expects a refusal.
- Define retention per field and automate expiry, because retention enforced by intention is not enforced.
- Build the erasure path early and trace it through replicas, caches, indexes, queues and log sinks.
- Redact personal data from logs, traces and error payloads at the logging layer.
- Issue one credential per consumer, rate limited, revocable without a deployment.
- Keep an [audit log](/glossary/audit-log/) of personal-data access that records who, what, when and under which purpose, and make it immutable.
- Name the breach owner and rehearse the runbook before you need it.
What this costs and when to do it
Designed in from the start, these controls add days rather than weeks to an engagement. Eazyware's API development and integrations work runs from $7,000 or ₹4,40,000 to $35,000 or ₹23,20,000 depending on the number of systems in scope, with schema tagging, scoped authorisation, retention jobs and audit logging treated as part of the build rather than as an extra. Ongoing work, which is where compliance actually lives, sits in a Care Plan from $1,000 or ₹68,000 a month, with 24x7 cover and a named engineer at $5,250 or ₹3,40,000. Current ranges are on the pricing page.
The expensive version is the other order. Adding erasure and purpose tracking to a live API with six integrated consumers means changing a published contract, coordinating migrations across systems you do not control, and backfilling history you never recorded.
Where a checklist is the wrong tool
A checklist cannot decide whether you should hold the data at all. The cheapest compliance decision available is not collecting a field, and no amount of control design beats that. Before mapping obligations to controls, delete the fields nobody uses; teams routinely find that a third of the personal data in an integration exists because it was in the source system, not because anything reads it.
A checklist is also the wrong tool when your organisation has no named owner for the answer. Compliance is a continuing obligation held by a person, not a state a codebase reaches. If nobody owns consent records, retention decisions and the breach runbook, the controls will be implemented once and will drift within two release cycles. And on the legal interpretation itself, this article is engineering guidance: your counsel decides what applies to your business.
A worked example
For an NBFC handling KYC and loan onboarding, the personal data was the product: identity documents, addresses and financial records moving between an onboarding application, a document processing pipeline and a core lending system. The architecture kept processing inside the client's own environment, scoped each service account to the fields it needed, logged every read against a purpose and gave operations staff a reviewed exception path rather than broad database access. The KYC document intelligence case study describes the system.
Related reading
What the DPDP Act means for Indian companies covers the obligations beyond the API layer, and security patching cadence for production applications covers the part of reasonable safeguards that is purely about keeping current.
Compliance for an API is five properties of the data model, and they are cheap at specification time and punishing afterwards.
Frequently asked questions
Does the DPDP Act require personal data to stay in India?
▾
The Act does not impose blanket localisation on all personal data, but sector regulators and enterprise contracts often do. Decide residency once and enforce it with infrastructure: an Indian region for primary storage and backups where the obligation applies, private networking between services, and an explicit list of third parties receiving personal fields.
What is the most common security failure in APIs handling personal data?
▾
Broken object-level authorisation: an endpoint that returns any record whose identifier is supplied, because ownership is never checked server-side. It passes functional testing since tests use identifiers the caller owns. The fix is a server-side ownership check on every object plus a negative test that requests another tenant's record.
When should compliance controls be built into an API project?
▾
At specification time. Tagging personal fields, attaching a purpose to reads, defining retention per field and building the erasure path add days to a build. Adding the same controls to a live API with several integrated consumers means changing a published contract, coordinating migrations and backfilling history nobody recorded.