> For the complete documentation index, see [llms.txt](https://help.delpha.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.delpha.io/delpha-api-and-mcp/api/data-sources-and-privacy.md).
# Data sources and privacy
Several operations return information about a person. This section states **where a result comes from**, **what personal data leaves Delpha and to whom**, **how long each store keeps it**, **the role Delpha plays**, and **how anyone whose data was checked can reach Delpha**.
**Delpha holds no contact database.** No operation is answered from a stored list of people: Delpha does not build, buy, rent or sell one. Every result is computed at the moment of the request, from the values in that request together with Delpha's own reference data and, for some operations, a check with a third-party provider.
**What leaves Delpha.** The table covers every single-record operation: first the ones that can return information about a person, then the ones that concern a company. Each row applies to that operation's `/batch` counterpart as well, where one exists, except that the batch phone route contacts no provider at all.
| Operations | Where the result comes from | What leaves Delpha, and to whom |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `POST /v1/email` | Delpha's own verification and a Delpha model. No contact database and no third-party database. Candidate addresses are generated from per-domain address patterns, not retrieved from a list of known addresses | The address you supply — or an address formed from the name and company website you supply — reaches the mail infrastructure of that address's own domain. No contact-data provider is queried |
| `POST /v1/phone`, `GET /v1/phone` | The submitted number, parsed and verified against data from carriers and cross-carrier network enablers, through Delpha's providers. Delpha verifies only the number itself (validity, line type, carrier, connection status) and does not link it to an individual, a name or any other personal data | The number in E.164 form and a two-letter country code, to those providers. Nothing else |
| `POST /v1/name` | Delpha's own reference data | Nothing. This operation contacts no third party |
| `POST /v1/linkedin-profile` | Public web search in real time: Google results, retrieved through Google Custom Search API or a SERP provider. No LinkedIn account, session or credential, no contact database and no third-party database | The name, company and country you supply, to that search provider. An email address you supply never leaves Delpha: only its domain is used, as a company website, which is requested directly only when no name is given. A URL you submit for validation is never requested: its format is checked, and it may be searched for through that search provider |
| `POST /v1/linkedin-company-page` | The company website, and public web search: Google results, retrieved through Google Custom Search API or a SERP provider. No LinkedIn account, session or credential, and no third-party database | The company name and country you supply, to that search provider. The company website you supply — or the domain of an email address you supply, which itself never leaves Delpha — is requested directly. A URL you submit for validation is never requested: its format is checked, and it may be searched for through that search provider |
| `GET /v1/company` | Delpha's own company datalake | Nothing. This operation contacts no third party |
| `POST /v1/website` | Public web search and the company's own website | The company name and country you supply, to a web-search provider and to Delpha's AI provider. The website itself is visited |
| `POST /v1/legal-id` | Delpha's company datalake and public company registries | The name or identifier you supply, to the selected country's registry when needed. A company found there is added to the datalake |
| `POST /v1/ultimate` | Web search by Delpha's AI providers, and GLEIF's LEI register | The company name, website and country you supply, to Delpha's AI providers; the parent's name, to GLEIF |
Delpha's providers are **named individually, with the role each one plays**, in Delpha's sub-processor list: . That list is the authoritative record and is kept current; each provider receives only the values its row above names.
**How long each store keeps something.** Every figure below is the one the service applies today.
| What is kept | Where | For how long |
| ------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| The full job result, so it can be polled | The job record behind `GET /v1/{usecase}/{job_id}` | 10 days |
| The request input, projected through a per-operation allowlist, and the result that was served, in full | Your team's resolution history | The window your team configures — 30 days on the free tier, up to 180 on a paid plan. Set to 0, neither is stored |
| Batch item lists, and batch result files | The batch file store behind `result_url` | Item lists 7 days, result files 30 days |
| Call metadata — the operation, the caller and the timestamp. No request input and no result | Your team's usage log | Retained for the life of the account; it is append-only |
| Operational logs | The service's log groups | 3 days |
| Companies a legal-ID lookup adds to the datalake | Delpha's company datalake | No expiry: company reference data |
**Role and legal basis.** For every call, the customer submitting the data is the controller; Delpha processes it on the customer's behalf and on the customer's instructions (GDPR Art. 28). Under the CCPA/CPRA, Delpha is the customer's service provider and does not sell or share personal information. The lawful basis for a call is the customer's; for verifying business contact data it is typically legitimate interest (GDPR Art. 6(1)(f)) in keeping records accurate (Art. 5(1)(d)).
Delpha is the controller of one store it keeps across customers: its verification cache, whose verdicts are keyed by a hash of the value and kept up to 30 days so the same address or number is not checked again. Its basis is Delpha's legitimate interest.
**If your data was checked.** Anyone whose email address, phone number, name or LinkedIn URL was submitted to Delpha can write to to ask whether Delpha holds it, and to have it corrected or erased from job records, resolution histories and the verification cache. Delpha answers within one month and forwards the request to the customer concerned, so they can act on their own records. The rights this covers are set out in Delpha's privacy policy:
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://help.delpha.io/delpha-api-and-mcp/api/data-sources-and-privacy.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.