Current status
We do not currently offer a pre-signed, templated Data Processing Addendum, because we do not process personal data on behalf of a customer in the way a typical SaaS processor/controller relationship assumes — see roles below for why.
Processor / subprocessor roles
In a standard DPA, one party is the "controller" (decides why and how personal data is processed) and the other is the "processor" (processes it on the controller's instructions). BhuBharati Explorer doesn't cleanly fit either role for a typical integrator, because:
- the personal data involved (pattadar/owner names, extents) originates from, and is already published by, the Telangana government's BhuBharati portal — we are not collecting it from you or on your instructions;
- we hold no account or customer relationship with API/MCP callers, so there is no defined "controller" giving us processing instructions in the GDPR Article 28 sense;
- if you build a product on top of our API/MCP server and that product has its own end users, you are likely the controller for your own users, and we act more like an upstream public-data source than a processor of your customers' data.
If your specific integration does create a genuine controller/processor relationship (for example, you send us identifying information beyond a location lookup), contact us — see Contact — to work out the actual roles before assuming standard DPA language applies.
Subprocessors
| Party | Role | When involved |
|---|---|---|
| Hosting / infrastructure provider | Runs the application containers and network | Always |
| Telangana BhuBharati portal | Source of the underlying public land-record data | Every record fetch |
| OpenAI | Optional AI-assistant provider — see LLMs | Only if a self-hosted operator explicitly enables it; disabled in our production deployment |
GDPR-relevant terms
We do not target or knowingly serve EU/EEA residents as a primary audience — this is a Telangana, India land-records tool — but we design the same way regardless: minimal data collection, no accounts, no unnecessary retention, and clear disclosure of the one optional AI path. If you are integrating on behalf of an EU entity and need specific commitments (data subject request handling, breach notification timelines, records of processing), raise them with us directly rather than assuming a template covers your case.
Cross-border transfers / SCCs
Our infrastructure and the government data source are located in relation to India; if your integration involves EU personal data crossing into a jurisdiction that requires Standard Contractual Clauses or an equivalent transfer mechanism, contact us to discuss your specific flow — we do not have a standing SCC template published today.
If you need a signed DPA
We're open to reviewing and executing a reasonable DPA for an organization that genuinely needs one for its own compliance obligations. Reach out with your use case, what personal data (if any) would flow through the integration, and your required terms, and we'll work through it — this page is not a substitute for that conversation.
Contact
Start a DPA or subprocessor conversation through the project repository or the API documentation at /docs.