Privacy Policy

PeopleDat is operated by Pixel Reef LLC, a Florida limited liability company. This policy describes how PeopleDat handles information when you visit the website, create or use an account, submit email addresses for verification, buy a subscription or credits, install a widget, use developer tools, or contact us. It covers PeopleDat's handling of that information, not the separate practices of customers or outside services.

If you use PeopleDat for an organization, that organization may have its own responsibilities and policies for the addresses and source columns it submits, the people it invites, widget visitors it chooses to process, and the results it receives. Organization owners and administrators control workspace access and may be able to view, export, retain, or delete information that members submit for the organization. Agencies must be authorized by each client whose information they process.

PeopleDat determines how and why it handles website visits, account and membership records, billing and financial records, support messages, security data, service analytics, and the protected cross-customer verification cache. For those activities, PeopleDat generally acts as the controller, business, or equivalent responsible party under privacy laws that use those terms.

A customer determines why it submits third-party email addresses, source rows, exclusions, and widget requests and how it uses the returned results. When PeopleDat handles that information solely to provide the requested workspace service, the customer is generally the controller or business and PeopleDat is generally its processor or service provider. The customer must give required notices, establish a lawful basis, respond to the people whose data it controls, and issue only lawful instructions.

Because PeopleDat independently determines the purpose and operation of the global result cache, cache handling is described separately below and is not represented as processing solely on one customer's instructions. An executed data-processing addendum may allocate additional responsibilities for covered customer processing.

The categories depend on how you use PeopleDat:

• Account and sign-in information: email address, name, verification status, account and organization, membership, role and workspace identifiers, invitations, access grants, session records, notification preferences, and sign-in-provider information if you choose an available Google or GitHub sign-in option.
• Verification information: email addresses, list and file names, uploaded or pasted list contents and ordered source cells, import classifications, exclusions, job and schedule details, verdicts, technical checks, result history, change reports, report aggregates, and export files.
• Billing information: the plan or credit pack selected, amount, currency, status, and Stripe customer, Checkout Session, PaymentIntent, and subscription identifiers. Full payment-card details are entered with Stripe rather than stored in PeopleDat's application database. PeopleDat may retrieve limited payment-method details, such as card brand and last four digits, from Stripe for the billing screen.
• Messages: the name, reply address, subject, message, category, and related information you include in contact or support requests, and records needed to send sign-in emails.
• Usage, device, and security information: request path, date and time, browser or device information, service events, error and diagnostic information, and network information used for abuse prevention. Some rate limits use a keyed or salted representation of an address or IP rather than the raw value.
• Developer and integration information: API-key name, environment, prefix and last four characters, scopes, limits, usage and revocation history; webhook URLs, selected events, delivery status and bounded response diagnostics; widget site keys, exact allowed origins, caps and coarse outcomes; MCP request identifiers; and idempotency records. Secret API keys and webhook signing secrets are shown once and stored only as a hash or encrypted value, as applicable.
• Widget visitor information: when a customer installs the PeopleDat widget, PeopleDat may receive the address entered for checking, the widget and workspace identifiers, exact page Origin, a customer-generated request identifier, and network or abuse-prevention signals. The customer decides where to install the widget and is responsible for its notice and lawful use.
• Optional analytics information: only after you allow analytics, Google Analytics may receive page title, route, session, browser, device, and approximate location information. Current funnel events can also include the selected call-to-action, sign-in method, list input source, aggregate list and result counts, verification verdict or failure category, rerun status, credits used, and the selected plan or credit pack. These events are designed to omit submitted email addresses, uploaded file and list names, list contents, query strings, and URL fragments.

Please submit only the information needed for verification or support. Do not place passwords, payment-card numbers, or unrelated sensitive information in uploaded files or messages.

PeopleDat receives information from:

• you, when you create an account, make a purchase, configure a feature, or contact us;
• your organization, team administrators, agency, clients, and other users who invite you or submit information;
• customers that submit third-party addresses, source rows, or widget requests for verification;
• your browser, device, and network when you visit or make a request;
• Stripe, sign-in providers, and other subprocessors that return transaction, identity, security, or delivery status; and
• the Service itself, which creates results, usage, audit, billing, and diagnostic records.

PeopleDat does not obtain lists from data brokers for enrichment or resale. A customer may have obtained an address elsewhere, and that customer—not PeopleDat—controls the original source and collection context.

PeopleDat uses information to:

• authenticate users, maintain sessions, and operate accounts and workspaces;
• parse lists, perform requested checks, display results, and create exports;
• operate team access, agency workspaces, exclusions, notifications, schedules, public reports, APIs, webhooks, widgets, and MCP tools;
• reuse a sufficiently recent result when the protected verification cache has a match;
• administer subscriptions, one-time credit purchases, balances, invoices, and billing support;
• send sign-in links and respond to contact or support requests;
• enforce limits, investigate errors or misuse, secure the service, and prevent fraud; and
• measure website and funnel use with Google Analytics only after consent.

Information may also be used or preserved when reasonably necessary to respond to a valid legal request, protect users or the service, resolve disputes, or document a transaction.

Where applicable law requires a legal basis, PeopleDat relies on performance of a contract for account, verification, workspace, and billing operations; legitimate interests in securing, supporting, measuring, and improving the Service and preventing abuse; consent for optional Google Analytics; and legal obligations for tax, accounting, sanctions, fraud, dispute, and lawful-request records. A customer must establish its own legal basis for third-party addresses and widget visitors it instructs PeopleDat to process.

An organization owns its memberships, billing relationship, pooled credits, and workspaces. Owners and administrators receive broad access across the organization; contributors and viewers receive the explicit workspace access assigned to them. A workspace is the boundary used to isolate lists, jobs, exports, credentials, rules, reports, schedules, and usage. Removing a person does not automatically erase shared work or financial records, and creator attribution can remain after the user leaves.

A client workspace is designed to keep one agency client separate from the agency's default workspace and other clients. Client users can see only people with access to their client workspace, but agency owners and administrators can access every client workspace. Organizations should invite only authorized people, review access regularly, and set member or workspace spending caps where appropriate.

API and MCP requests use workspace-bound credentials. PeopleDat records privacy-limited request metadata such as the key and workspace identifiers, route template, status, duration, aggregate counts, source, and billed units. Request bodies, raw addresses, raw credentials, and raw IP addresses are not retained in API request logs. Customers are responsible for protecting API and webhook secrets and revoking them if exposed.

Webhook and email notifications contain identifiers, deep links, status, aggregate counts, and credit use—not submitted addresses or source columns. Delivery diagnostics can include attempt time, HTTP status, error class, and a bounded response excerpt. Public report snapshots contain aggregates only. A report's bearer token is placed in the URL fragment and exchanged by POST, but anyone who receives that token can open the report until it expires or is revoked, so customers should share it carefully.

The browser widget returns coarse advisory outcomes. Site keys and browser Origin headers are not secrets. Customer-configured origin allowlists, rate limits, anomaly pauses, and daily hard caps reduce exposure. During an outage, timeout, unknown result, or insufficient-credit condition, the widget is designed to fail open.

PeopleDat checks its verification cache before requesting a new provider result. When a fresh usable result is not available, PeopleDat sends the email address—or addresses in a bulk task—and the request details needed to perform the check to Reoon, the email-verification provider used by the service. Reoon returns technical verification fields and a verdict that PeopleDat maps into the result shown to you.

Email verification describes technical conditions observed at a point in time. It does not establish a person's identity, consent, interest, or future deliverability. You are responsible for having permission to submit the addresses and for how you use the results.

To avoid repeating an outside verification request unnecessarily, PeopleDat maintains a result cache. For lookup, an address is normalized and combined with a private salt before it is hashed. The current application stores the corresponding address in encrypted form and stores a filtered provider result. A salted hash is a security control, not a claim that the data is anonymous.

The cache can operate globally. If one customer later submits the same address that another customer submitted, PeopleDat may return the sufficiently recent cached verification result instead of sending a new request to Reoon. The later customer must already know and submit that address. Cache reuse does not reveal another customer's list, account, workspace, file name, or the fact that a particular customer previously submitted the address.

Cache freshness and retention are separate. A result that is too old to serve may remain in protected storage until a maintenance cleanup or valid deletion request removes it. A request concerning cache data should name the specific email address so PeopleDat can locate its salted lookup value after verifying the request.

PeopleDat uses the following subprocessors and service-provider categories for the functions described:

• Reoon for requested email-verification checks;
• Stripe for Checkout, subscriptions, one-time purchases, invoices, payment-method management, tax features used by subscription Checkout, and payment event delivery;
• Resend for sign-in, invitation, notification, contact, and support email delivery;
• Railway for application hosting and deployed database infrastructure; Redisfor queue, cache, rate-limit, and coordination data; and the configured S3-compatible object-storage provider for encrypted generated exports;
• Cloudflare Turnstile for bot and abuse checks on protected forms; Cloudflare receives the challenge response and technical information needed to evaluate it, which can include the client IP and browser or device information;
• Google Analytics for optional website measurement after you allow analytics; and
• Google or GitHub if an available third-party sign-in option is enabled and you choose it.

Provider and storage configurations can change as the service evolves. PeopleDat will update this policy when a change materially affects the processing described here. The current operational list is available on the Subprocessors page.

These services have their own terms and privacy practices. PeopleDat may also disclose information when reasonably necessary to comply with a valid legal process, address fraud or misuse, protect rights or safety, or evaluate or complete a financing, sale, merger, reorganization, or transfer involving the service.

Necessary cookies and browser storage support sign-in, security, and remembering your privacy choice. Optional Google Analytics does not load until you choose Allow. Rejecting analytics does not block the core verification service, and you can reopen Cookie Settings to change your choice.

Read the Cookie Policy for the categories, controls, cookie names, and Google's documented default durations.

PeopleDat does not sell customer lists, submitted addresses, source columns, account records, or verification results for money. PeopleDat does not disclose Customer Data to Google Analytics and does not use Customer Data or verification addresses for cross-context behavioral advertising.

Optional website analytics is limited to consented measurement described in the Cookie Policy. PeopleDat will honor a legally valid request to opt out of a processing activity if an applicable law treats that activity as a sale, sharing, or targeted advertising, even when PeopleDat does not receive money for it.

PeopleDat uses the following default or maximum operational retention periods:

• account, organization, membership, and workspace configuration ordinarily remains while the relationship is active and through a reasonable account-closeout period;
• encrypted source rows and original columns follow the workspace choice of 7, 30, or 90 days, or until the list is deleted; 30 days is the default;
• verification results can remain after source columns expire and ordinarily remain while the related workspace or list remains active;
• generated exports expire after 30 days; signed download links expire sooner;
• API request logs and in-app notifications are kept for 90 days;
• idempotency records are kept for 24 hours;
• anonymous verification-preview records are eligible for deletion after the 48-hour abuse-prevention cooldown;
• webhook and email delivery diagnostics are kept for 30 days;
• domain-event replay data is kept for 30 days, after which aggregate usage may remain;
• terminal queue and scheduler diagnostics are kept for 30 days;
• workspace, security, and API audit events are kept for two years;
• Stripe identifiers, purchases, subscription history, wallets, credit ledgers, invoices, and related financial records are ordinarily kept through the end of the seventh calendar year after the latest related settlement, refund, reversal, chargeback, subscription end, material ledger adjustment, or dispute resolution;
• public report links expire after seven days by default and never more than 30 days; and
• expired sessions, verification tokens, rate-limit counters, and seven-day organization invitations are removed by scheduled cleanup;
• protected verification-cache entries follow a separately configured operational window and may remain after a workspace record is removed because the cache is not tied to a customer's list context;
• provider systems follow their own documented operational or deletion windows; and
• backup copies roll off through the applicable backup cycle and are isolated from ordinary application use.

A legal hold, tax examination, fraud investigation, chargeback, security incident, or active dispute pauses deletion only for the records reasonably needed for that matter. After the hold ends, the ordinary period resumes or the record is deleted if its period already ended. Deleting a list or account can remove or disconnect many related records, but deletion may not be immediate or complete where a record must be retained for security, reconciliation, backup cycling, another person's rights, or a valid legal obligation.

Current safeguards include access checks, bounded uploads and request bodies, application-level encryption for email and source-cell storage, salted or keyed lookup values, hashed API keys, encrypted webhook secrets, tenant-scoped authorization, limited logs, signed export links, outbound webhook destination controls, and payment processing through Stripe.

No safeguard makes an online service risk-free. Encryption and hashing reduce risk but do not make information anonymous or eliminate the possibility of unauthorized access, provider failure, transmission error, or data loss. Contact [email protected] promptly if you believe an account, credential, integration, or submitted information has been compromised.

PeopleDat is operated in the United States, and PeopleDat and its subprocessors may process information in the United States and other countries. Privacy and government-access rules can differ between locations. Where an applicable law requires a transfer mechanism, PeopleDat will use an available lawful mechanism appropriate to the transfer, such as an adequacy decision, contractual safeguards, or another permitted basis. Contact the privacy address below to ask about the mechanism applicable to a specific covered transfer.

You can review information available through your memberships, delete individual source columns, lists, or exports where the service provides that control, revoke developer credentials and report links, manage your notifications, cancel a subscription if you are the organization owner, reject optional analytics, and change your analytics choice later. Organization owners and administrators may act on shared workspace information; an individual member may not be able to override the organization's authorized retention or legal obligations.

Depending on where you live and the circumstances, you may be able to ask to know or access information about you, correct it, delete it, receive a portable copy, limit use of sensitive information, object to or restrict processing, opt out of a sale, sharing, targeted advertising, or qualifying profiling, or withdraw consent. You may also have a right to appeal a denied request or complain to a privacy regulator. PeopleDat will not discriminate against you for exercising a privacy right.

PeopleDat will verify the requester and assess the request under the rules that apply. An authorized agent may submit a request where permitted, but PeopleDat can require proof of authority and direct identity verification. A request may be limited where it cannot be verified or conflicts with security, transaction records, another person's rights, or a valid legal obligation.

If your information was submitted by a PeopleDat customer, contact that customer first because it controls the original list, widget, campaign, and processing purpose. PeopleDat will support a verified customer instruction where required. A request about the protected cache should identify the exact email address so PeopleDat can locate the salted lookup value after appropriate verification.

Send a request or appeal to [email protected]. State that the message is a privacy request or appeal and include enough detail to identify the account, workspace, list, export, widget interaction, or cache entry. Do not email passwords, card details, API keys, or identity documents unless PeopleDat first provides a secure method.

Browser-based opt-out signals such as Global Privacy Control are honored where legally required for processing that the signal covers. The Service does not respond to older “Do Not Track” signals that do not convey a legally recognized choice. Optional analytics remains controlled by PeopleDat's Cookie Settings.

PeopleDat is a business and professional service for adults, is not directed to children, and may not be used by anyone under 18. Do not create an account for a minor or submit a minor's information. Contact [email protected] if you believe a minor's information was submitted so PeopleDat can investigate and take appropriate action.

PeopleDat may update this policy as the service, providers, or data practices change. The current version and effective date will be posted here. Material changes may also be communicated through the service when appropriate.