Privacy Policy

1. Who we are and what this covers

Enrichments is a B2B contact and company enrichment service. Customers describe the people or companies they are looking for — in natural language, through our API, or by uploading a CSV — and we return structured business records: names, job titles, employers, work email addresses, LinkedIn profile URLs, company domains, and similar firmographic detail.

This policy covers the enrichments.iowebsite, the product, and the API. In it, "we" and "Enrichments" mean the operator of the service at enrichments.io. You can reach us about anything in this policy at privacy@enrichments.io, and that mailbox is the route to us for every right and request described below.

2. The two groups of people in this policy

Most privacy policies describe one relationship. Ours describes two, and conflating them would be misleading:

• Customers — the people who create an account, sign in, spend credits and use the API. We collect their data because they gave it to us in order to use the product. Sections 3 and 11 are about them.
• Data subjects in our records — the professionals whose business-contact details appear in enrichment results. They did not sign up, did not provide their data to us, and in most cases will never interact with us. We hold data about them anyway, because that is what the product does. Sections 4, 5 and 12 are about them.

Under European and UK data protection law we are a controller of both kinds of data, and we are not a processor of either. For customer account data, the collection is our decision rather than a customer's instruction: we decide that an account needs a name, an email address and a password hash, that a session records the IP address and browser it was created from, and how long any of it is kept. For the business-contact records described in Section 4 we likewise decide what to collect and how to store it, with no customer directing us. We say this plainly because the distinction determines whose responsibility it is to answer a data subject: in both cases, it is ours. That is also why the rights in Section 11 — access, correction, erasure, objection, and complaint to a supervisory authority — are exercisable against us directly.

3. Information we collect from customers

• Account information — your name, email address, and a password. Passwords are stored only as a hash; we never store or have access to the plaintext. If you sign in through a third-party identity provider instead, we store the account identifier and the tokens that provider issues for sign-in. That provider is used for authentication only — we never request or receive access to your mailbox, your files, or any other service you hold with it.
• Organization information — the organization you belong to, your role in it, members you invite, and the API keys minted for that organization.
• Session information — a session token, its expiry, the IP address the session was created from, and the browser user-agent string. These are what let us keep you signed in and let you see where your account is being used.
• Requests you make — the search queries you type, the filters and fields you request, the chat messages you send to the in-product agent, and the identities (names, companies, domains) you submit for enrichment.
• Uploaded files — when you upload a CSV, we store the filename, the detected delimiter, the file size, every column header, and every parsed data row. That includes columns we do not enrich and rows we decline to process. The rows live in our database; we do not keep the original file bytes and we do not use object storage. Uploads are capped at 4 MB.
• Enrichment results and provenance — the records returned for each job, plus per-field evidence recording which provider and endpoint produced each value and with what confidence.
• Credit and billing records — an append-only ledger of every credit granted, purchased or consumed by your organization, and what it was spent on.
• Campaign and advertising identifiers, if you consent to them — the campaign parameters on the link you arrived through (the utm_ values), the click identifier an advertising platform appends to that link, the website that referred you, and the path of the page you landed on. If you then create an account, that set is copied once onto your account record so we can tell which campaign it came from. Nothing is collected at all unless you have consented, and Section 10 describes the cookie, the consent and how to refuse or withdraw it.

What changed, and when. This section previously said that we ran no analytics of any kind and that there was no advertising pixel anywhere in the product or on this site. That is no longer true, and we would rather say so in the same place the old sentence stood than quietly delete it. We now run web analytics and advertising conversion measurement on the public marketing pages, subject to your consent. What that means concretely — the categories of cookie, what leaves our systems, and how to say no — is set out in Section 7 and Section 10, and none of it runs before you have agreed to it where your consent is required.

Three limits on it are worth stating here rather than leaving you to infer them. We do not run any analytics, session recording or advertising measurement on the pages inside the product itself: the URLs of your enrichment jobs, uploads and conversations are never sent to an advertising platform. The queries you type, the files you upload and the results you receive are never used for advertising and never reach one of these platforms. And we still do not operate an error-reporting service, and there is no session recorder anywhere.

We do send transactional email, and only transactional email. There are exactly four messages: a confirmation link when you sign up, a password-reset link when you ask for one, a notice that your password was changed, and an organization invitation. They carry no marketing content and no mailing list to be added to, and we do not turn on open or click tracking for them. We never send email on your behalf, and the product has no outreach, sequencing or mailbox-connection functionality. Section 7 names the category of provider that delivers them and exactly what it receives.

4. Personal data about people who are not our customers

This is the part of our processing that most distinguishes Enrichments from ordinary SaaS, and we would rather over-explain it than bury it.

What we hold. For an individual, our records may contain: full name and its parts; current job title, seniority and department; employer name and company domain; a work email address and an indication of whether that address appears deliverable; a LinkedIn profile URL; a professional headline; city and country; a confidence score; and the normalised payload our upstream provider returned. For a company: name, domain, LinkedIn URL, description, industry, headcount, location, country, founding year and logo.

Where it comes from. We do not crawl the web. Most of what we hold is sourced through an upstream B2B data and web-search provider, which derives it from publicly available web content and, for some lookups, routes the request onward to a third-party B2B contact database through its own connector layer. For that data we are at least one step removed from the original collection, and we cannot always establish how a given fact was first obtained.

One category of email address is generated by us, not found. We say this separately because it is the one place the paragraph above does not apply. When no published work address can be found for someone, our email service may CONSTRUCT candidate addresses from that person's first name, last name and their employer's domain — the common shapes such as first.last@ or flast@ — and then ask that domain's own mail server whether the mailbox exists. An address produced this way was never published anywhere, was never supplied by the upstream provider, and has no source web page behind it. We record it as such: its stored evidence carries the source pattern.probeand no source URL, it is never marked verified on the strength of the construction alone, and it is discarded rather than shown when the domain accepts every address it is offered and we have learned nothing about that domain's shape. If you are asking us what we hold about you, this is the category to ask about by name, and Section 12 tells you how.

How it is stored.There is no single canonical profile of you in our database. A record is stored per job: when a customer runs an enrichment, the result and the per-field evidence behind it are written to that job's rows inside that customer's organization. If four customers look the same person up, there are at least four copies, in four organizations — one per job, so a customer who runs the same lookup twice holds two. Our schema does contain globally deduplicated person and company tables — one row per LinkedIn profile URL, one per company domain — but no code writes to them, and they are empty. We would rather tell you that than let their existence imply a single record we can reach in one operation, because the difference is exactly what makes an erasure request in Section 12 a search rather than a delete.

Two other stores need calling out, for two different reasons:

• Our upstream response cache is the one store that is not organization-scoped at all. It is keyed by a hash of the request and shared across every customer by design, and it holds the request as well as the response — so the names, companies and domains one customer submitted are kept there too, not only the answer that came back. Section 9 covers how long.
• Uploaded CSVs are organization-scoped like everything else, but their contents are chosen by the customer rather than by us. A file is stored whole and in file order, including the columns we do not enrich and the rows we declined to process, so it can contain categories of data we would never go looking for. Section 5 gives the case that matters most.

Lawful basis. Where European or UK data protection law applies, we rely on legitimate interests as our basis for holding professional contact data: the interest is operating a business-contact directory that other businesses use to reach the right person at work, and we balance it against the interests, rights and reasonable expectations of the people described in our records. One thing follows from that balance and is built into the product rather than merely asserted here: the scope is professional — names, job titles, employers, work email addresses, mobile numbers where a customer asks for them, public professional profiles and company firmographics, with no home addresses, no personal accounts and no special-category data. Section 5 sets out the narrow terms on which a phone number is returned and the obligations that calling one places on you rather than on us.

A second obligation follows from the fact that this data did not come from you. Where personal data is obtained from a source other than the person it describes, European and UK data protection law requires that person to be told anyway — Article 14 of the GDPR and its UK equivalent — and the notice you are reading is how we discharge that duty. It is published at a fixed public address, readable without an account, linked from the site footer and from the sign-up form, and written so that someone who has never heard of us can find out what we hold and have it erased. Section 12 is that route, and it is open to anyone without an account and without a reason.

Legitimate interests is a basis you can object to, and an objection is not a request we weigh against our commercial interest in keeping the record. Tell us at privacy@enrichments.io that you do not want to be in our records and we will remove you, without asking you to justify it — subject to the practical limits set out at the end of this section, which we would rather you knew in advance. If your view of the balance differs from ours, that is a disagreement you are entitled to take to your supervisory authority, and Section 12 says so.

A note on "selling" data.We do not sell, rent or trade our customers' account data — not to anyone, for any purpose. Separately and honestly: supplying business-contact data to paying customers is the entire function of this product, and under some US state privacy laws, including the California Consumer Privacy Act as amended, disclosing personal information for monetary consideration can meet the statutory definition of a "sale" regardless of what we call it. We are not going to print a flat "we do not sell your data" that a regulator could read as inaccurate, and we are not going to assert the opposite conclusion as settled either — the characterisation turns on facts about each transaction and on law that is still moving.

So we have done the thing that does not depend on which way that question lands: we operate the opt-out regardless. If you do not want your business-contact details supplied to our customers, write to privacy@enrichments.io and say so — no account, no verification of a residency, no explanation required — and we will delete the records we hold about you and stop supplying them. This is the same route as the erasure request in Section 12, and it is deliberately not gated on whether any particular statute applies to you.

What that opt-out cannot do, said before you rely on it. It is a deletion we perform, not a filter that runs by itself. We do not operate a suppression list today — there is no do-not-disclose table in our database — and we do not delete you at source. So if a customer runs the same lookup again after the cached answer has expired (Section 9 gives the windows), our upstream provider can return you to us a second time, and the record would exist again until it is removed again. Your instruction stands and we will act on it each time you tell us you are back; what we cannot honestly claim is that one email makes you permanently unreachable through this product. Section 12 explains the same limit for erasure, and says where to go to be removed at the source.

You are also entitled to ask what we hold, to have it corrected, and not to be treated differently for asking; Section 12 sets out how, and it applies to everyone in our records rather than to the residents of any one state.

5. Phone numbers

Enrichments returns mobile phone numbers, and until July 2026 it did not. An earlier version of this notice said the product was built so that it could not, and described that as a boundary enforced in code rather than promised in prose. That is no longer true, and a privacy notice that overstates a restriction is as much a defect as one that understates a practice. This section describes what the product does now.

What we return, and only when asked.A mobile number, resolved from a person’s public professional profile URL. It is not part of the default field set: a caller who does not name the phone field never receives one, and nothing in the product adds it on their behalf. You are charged only for a number actually found, on the same terms as every other field.

It is not verified, and we do not imply that it is. Work email addresses carry a deliverability check and a verdict recorded against each address. There is no equivalent for a phone: the source publishes no confidence, no recency and no line type, so a number arrives unverified and is displayed and exported that way. Nothing in the product marks a phone number as checked, because nothing checked it.

Where a number does not come from. Two controls that predate this change still stand, and they are the reason the scope above is narrow rather than open-ended. We do not read phone columns out of a CSV you upload — those cells are stored with the rest of your file and copied back into your download untouched, exactly as Section 12 describes, but they are never sent upstream and never billed. And the unmodelled provider payload we keep alongside each record is still filtered for phone-shaped keys at every depth before it is stored or returned, so a number cannot reach you because an upstream source added a field nobody requested. A phone number in your results got there because you asked for one.

Calling a number is your decision and your obligation. A mobile number carries duties that an email address does not. In the United States the Telephone Consumer Protection Act and the national and state Do-Not-Call registries restrict who may be called, when, and with what technology; other countries have their own regimes and some require prior consent outright. We supply data. We make no representation that any particular number is lawful for you to dial, and you are the controller of that decision. If your use of these numbers requires a lawful basis, a consent record or a suppression check, obtaining it is your responsibility and not something this product performs for you.

The rights in this notice cover phone numbers too. A mobile number is personal data on exactly the same footing as a name or a work address. Everything Section 12 says about finding out what we hold, correcting it and having it erased applies to it without qualification, and the route is open to anyone, without an account and without a reason.

6. How we use information

• To run enrichments — resolve your query, call our upstream provider, normalise and deduplicate the results, and return them to you with per-field provenance.
• To operate the chat agent, which interprets your request, calls the same enrichment tools, and explains what it found.
• To create and secure accounts, authenticate sign-ins, scope every request to the right organization, and rate-limit API keys.
• To meter and bill usage against the credit ledger, and to show you what each credit was spent on.
• To cache upstream responses, so that repeating a question does not re-charge you or re-query the provider.
• To respond to support requests, to prevent abuse, and to comply with legal obligations.
• To measure our advertising — to see which campaign brought a visitor to this site, whether they signed up, and whether they later subscribed, and to report those conversions to the advertising platforms we buy from so their bidding is based on something real. Where European or UK law applies, the basis for this one is your consent and nothing else; you can refuse it outright and withdraw it later, and Section 10 says how.

We do not use your queries, uploads or results to build advertising profiles. They are never sent to an advertising platform, they are not part of what any pixel on this site transmits, and no advertising decision is made from them. We also do not sell, rent or trade them to advertisers, data brokers, list vendors or anyone else for that recipient's own purposes. The one disclosure that could be characterised otherwise is the one the product exists to make — delivering enrichment results to the customer who asked for them, for a fee — and Section 4 sets out plainly why we will not print a flat denial about that.

There is a second thing that sentence should not be read to cover, so we will state it rather than let the narrower claim do double duty. If you consent to advertising cookies, page-visit and conversion signals from this site — which pages you viewed, that a signup happened, that a subscription was purchased and for how much — are shared with the advertising platforms named by category in Section 7. Those platforms are not acting on our instructions when they receive that data: they use it for their own targeting, audience-building and measurement across other sites we have nothing to do with. That is a different thing from the paragraph above, and consenting is the only reason it happens.

7. Who we share information with

The categories of recipient below are the complete list, and each is described by what it does and what it receives rather than by brand name. Section 9 of our Terms of Service reserves the right to change which suppliers we use, and a disclosure written by category stays accurate when one is swapped, where a list of names would quietly go stale. What matters for your data is what leaves our systems and why, so each entry says precisely that.

• An upstream B2B data and web-search provider — receives your search queries and the names, companies and domains you submit for enrichment, and returns the person and company data the product is built on. Some lookups are routed onward by that provider to a third-party B2B contact database through its connector layer.
• A large-language-model provider — powers the in-product chat agent. It receives your chat messages and, for each enrichment the agent runs, a preview slice of the results. That preview includes third parties' names, job titles, employers, company domains, locations, email addresses and LinkedIn URLs. This is third-party personal data leaving our systems to a model provider, and we would rather say so than let you assume otherwise. What that provider does with data it receives is governed by its own terms for our account, which we do not restate here.
• An operator-owned email service — does two things, and the second one receives more than addresses, so both are stated. (1) Verification: it probes whether a mailbox appears deliverable, and for this it receives an email address and nothing else. (2) Address construction: when no published address can be found for a person, it receives that person's first name, last name and employer domain, builds the candidate addresses that domain's people plausibly use, and asks the domain's mail server to confirm one. On the enrichment surfaces the name and domain it receives are values you supplied on the row. Both halves are optional and off unless configured; neither is billed. Verification only ever runs on addresses the platform itself discovered — an address you supply is never sent for checking.
• A durable workflow and realtime-streaming platform — runs enrichment and chat jobs in the background and streams progress to your browser. Job events carry identifiers only, but the chat channel carries the agent's output, which includes result rows.
• An application hosting platform — serves this site and the application, and therefore processes every request made to it.
• A managed database host — stores everything described in this policy.
• A third-party identity provider — sign-in only, and only if you choose to sign in that way. We receive an account identifier and sign-in tokens; no mailbox, file storage or other service held with that provider is requested or granted.
• A transactional email-delivery provider — delivers the four account and security messages described in Section 3. It receives the recipient address and the content of the message, which is your name at most; it never receives enrichment results, uploaded rows, chat messages or credentials, and it is not used for marketing of any kind. When someone is invited to an organization, the address the inviter typed is sent to this provider in order to deliver the invitation — that is the one case where an address we hold about a person who is not yet a customer is passed to it.
• Webhook endpoints you configure — if you supply a webhook URL for a job, we POST the completion payload to it. That destination is chosen by you and is outside our control; the request is signed so you can verify it came from us.
• Advertising and conversion-measurement platforms — only if you consent, and only on the public pages of this website, never inside the product. Each receives, directly from your browser: the address of the page you are on and the address you came from, the advertising click identifier on the link you arrived through, your IP address, your browser's user-agent string, and an identifier it stores in a cookie on this domain. When a conversion happens it also receives that fact and, for a purchase, the amount, the currency and the transaction identifier. It never receives your name, your email address, your queries, your uploads or any enrichment result. Two things about these recipients differ from every other entry on this list and are worth reading twice: they are not processing on our instructions but for their own purposes, including building advertising audiences across other websites; and their processing continues under their own terms once the data reaches them, so withdrawing consent here stops us sending more but is not by itself an instruction they act on. Section 10 covers refusal and withdrawal, and Section 8 covers where this data goes.

We do not currently use a payment processor. Card payments are not enabled in the product, and no payment credentials are collected, transmitted or stored by us or on our behalf. We also do not use an error-monitoring vendor.

We may also disclose information where we are legally required to, or to establish, exercise or defend legal claims. If our business is transferred, information may transfer with it, subject to this policy.

8. International transfers

The providers listed above may process data outside your country, including in the United States. We are describing this as a fact rather than claiming a particular transfer mechanism: we have not represented here that any specific safeguard, such as Standard Contractual Clauses, is in place with each provider, because we are not in a position to assert that for every one of them today. If your organization requires a data processing agreement or a documented transfer basis, contact us at privacy@enrichments.io before relying on the service for regulated data.

The advertising and conversion-measurement platforms added to Section 7 are called out separately rather than swept into the sentence above, because the transfer they involve is different in kind. Their data does not pass through our servers at all: your browser sends it to them directly, and it leaves for the United States at the moment the pixel loads. We are not asserting a specific transfer safeguard for them either. What we can tell you is the control that exists — this transfer does not happen unless you consent to advertising cookies, and it stops for future page views when you withdraw that consent.

9. How long we keep information

We would rather describe our retention accurately than promise a schedule we do not currently run.

Cached upstream responses. Responses from our upstream provider are cached and re-used for a bounded period, after which they are treated as absent and the provider is queried again: seven days for people and company searches and for direct answers, fourteen days for page summaries, thirty days for agent runs, and twenty-four hours for lookups that returned nothing. Note carefully that this is how long a cached response is used, not how long the row exists — expired entries are ignored on read but are not deleted automatically today. A purge routine exists in the code and nothing calls it, so in practice these rows persist until someone removes them by hand. This cache is deliberately not scoped to a single organization, so one customer's cached lookup can serve another customer's identical query. It also stores the request, not only the response: the names, companies and domains submitted for a lookup are retained there alongside the answer, under the same absence of automatic expiry.

Everything else is retained until we delete it on request. Enrichment jobs and their per-row results and evidence, uploaded CSV contents, conversations and messages, and credit ledger entries currently have no automatic expiry. Sessions and one-time verification tokens expire on their own; nothing else does.

Campaign and advertising data. The attribution cookie described in Section 10 is set to expire ninety days after your last visit that carried campaign information. One caveat, because the real number is shorter than the stated one on a large share of traffic: Safari caps the lifetime of any cookie written by JavaScript at around seven days regardless of the expiry requested, so on that browser ninety days is a ceiling and not a description. If you create an account, the campaign values are copied once onto a record attached to your account, and that record has no automatic expiry — it is kept for as long as the account is, and it is deleted with the account. It is also separable: you can ask us to delete just that record, and keep the account, by writing to privacy@enrichments.io. Cookies set by the advertising platforms themselves have their own lifetimes, set by them and not by us.

Deletion you can perform yourself.You can delete a conversation from the product, and you can revoke or rotate an API key at any time. You can also clear the advertising cookies yourself at any time, from your browser’s own cookie and site data settings — see Section 10.

Deletion you have to ask us for. There is no self-service account deletion today. Deleting an account, an organization, an uploaded CSV or a set of enrichment results is a manual process handled by us on request — write to privacy@enrichments.io and we will action it. Two honest exceptions: credit ledger entries are immutable by design and are retained as financial records, and because of that an organization with billing history is archived rather than deleted outright.

10. Cookies and consent

This section used to say that we set exactly one cookie, that there were no analytics or advertising cookies and consequently no consent banner, and that if any of that changed this section would change first. It has changed, and this section is that change — written and published before any advertising pixel runs, because a promise of that shape is worth nothing if it is kept in the wrong order.

Strictly necessary — always set, no consent asked. The session cookie that keeps you signed in, with a short-lived cache so we are not reading the database on every request, and a cookie recording your cookie choices themselves. These are exempt from consent because the service you asked for cannot be delivered without them, and remembering that you said no is not something we should have to ask permission for.

Analytics — only with your consent. A first-party measurement cookie that tells us which pages of this website are visited and how people move through them. Its purpose is our own understanding of this site.

Advertising — only with your consent. Two things sit in this category. The first is a cookie we set ourselves, named enr_attribution, which records the campaign parameters and advertising click identifier on the link you arrived through, the site that referred you and the page you landed on — both the first time you came and the most recent time you arrived through a campaign. It is first-party and its contents stay with us, but it exists to measure advertising, so we treat it as needing the same consent as anything else in this category rather than claiming an exemption for it. The second is the cookies set by the advertising and conversion-measurement platforms described in Section 7, which those platforms read on other websites as well as this one. Nothing in this category loads on the pages inside the product.

How the consent works. Nothing in the analytics or advertising categories is loaded before you agree to it. Refusing is one click and it is the same size, in the same place, as accepting — you will not find the refusal hidden behind a second screen. The two categories are separate switches, so you can allow measurement of this site without allowing anything to be shared with advertising platforms. None of this is bundled into the checkbox on the sign-up form: agreeing to our Terms is not agreeing to cookies, and declining cookies does not affect your account or anything the product does.

Where the banner appears.We ask before setting anything in the United Kingdom, the European Economic Area and Switzerland, and — because we determine your region from your browser's settings rather than by looking you up, which is a judgement that can be wrong — anywhere we cannot confidently place you. Outside those regions these cookies may be set without asking first, and the steps described next are how you turn them off.

Changing your mind.You can block or delete these cookies at any time in your browser’s own cookie and site data settings, which we do not attempt to work around; doing so stops them being read or re-set on later visits. You can also write to privacy@enrichments.io to withdraw consent and we will action it. Withdrawal takes effect from that moment; it does not undo what was already sent to a platform before you withdrew, and Section 7 is explicit about that limit.

If we ever add a category to this list, this section changes first — the same undertaking as before, and this revision is the evidence that it means something.

11. Your rights as a customer

Depending on where you live, you may have the right to access, correct, export, restrict or delete your personal data, to object to certain processing, and to complain to your local data protection authority. To exercise any of these, contact privacy@enrichments.io. We will not discriminate against you for making a request. Some data is retained despite a deletion request where we have a legal or accounting obligation to keep it — see Section 9.

One right now applies that did not before, because we now rely on consent as a lawful basis for something: where we process on the basis of your consent — advertising and conversion measurement, and the analytics and advertising cookies in Section 10 — you may withdraw that consent at any time. Two ways, and neither requires an account or a reason: block or delete the cookies in your browser’s own settings, or write to privacy@enrichments.io and we will action it. Withdrawal does not make the processing that already happened unlawful, and it does not affect anything we do on a different basis — your account, your data and the product are untouched by it.

12. If you are in our records and you are not a customer

If you have found this page because your details appeared in an enrichment result, this section is for you. You do not need an account, and you do not need to explain why.

• Write to privacy@enrichments.io with the name, work email address or LinkedIn profile URL that identifies the record, and tell us what you want: a copy of what we hold, a correction, or erasure.
• We will confirm receipt and tell you what we found. We may ask for enough information to locate the right record and to be confident you are the person it describes — we will not ask for more than that, and we will not use what you send us for anything else.
• Erasure means we find and delete the copies we hold. Be aware of what that involves, because we would rather set the expectation than have you discover it: results are stored per job inside each customer's organization rather than as one canonical record, so this is a search across every organization's stored results, every uploaded file, and our shared upstream cache — done by hand, not a single delete. We will tell you when it is finished. We cannot retract data a customer already exported before your request, and where a value was derived from a public source we cannot delete you from the upstream provider or from the web pages it came from — you would need to contact those sources separately. That last sentence does not apply to a constructed email address (Section 4): nothing upstream holds it and no page it came from exists, so our copies are the only copies, and deleting them is entirely within our power. That last point has a consequence worth stating rather than leaving you to discover: because the source still holds you, a later lookup by another customer can bring your record back, and we would delete it again on the same request. Section 4 says the same thing about the opt-out.
• You can also object to our processing of your data generally, rather than asking for a specific correction.
• If you are unhappy with how we handle your request, you can complain to your local data protection authority.

On phone numbers, so that an answer to a request is not narrower than the truth: we do not look up, source or return them, so nothing we collect about you includes one — see Section 5. The exception is a customer's uploaded file. If someone uploaded a spreadsheet with a phone column, we stored that column as it was given to us without ever reading it. Those cells are inside the scope of a request for what we hold and inside the scope of an erasure, and we will search them.

13. If you are a customer: your own obligations

Buying data from us does not transfer our position to you, and it does not give you a lawful basis for what you do next. You are independently responsible for having a valid basis to process the contacts you obtain and to contact them, and for complying with the marketing, electronic communications and data protection rules that apply where you and your recipients are. You are also responsible for honouring opt-outs and erasure requests that reach you directly. Section 7 of our Terms of Service says the same thing in contractual form.

14. Security

Our security page describes what the product actually implements — session and API-key handling, organization-scoped access, signed webhooks, and a credit ledger the database itself refuses to rewrite. It also lists what we do not claim. No service can promise perfect security, and we do not.

15. Children

Enrichments is a business tool, is not directed at children, and is not intended for anyone under 18. We do not knowingly collect data from children. Our records are professional contact data by construction; if you believe a record describes a child, tell us and we will remove it.

16. Changes and contact

We will update this policy as the product changes, and we will move the "last updated" date at the top when we do. Material changes will be communicated in the product. Questions, requests and complaints all go to privacy@enrichments.io.