Privacy Policy

1. Data controller

ByeBouncer is operated by Fidel (sole proprietorship, Argentina). For any privacy request, contact hello@byebouncer.com. We aim to reply within 5 business days.

2. What we collect and why

2.1 Account data

• Email address — you provide it at sign up. Used to authenticate you, send security notifications, and reach you about the service.
• Password (hashed) — never stored in clear text. Hashed with bcrypt by our authentication provider (Supabase Auth).
• User ID — an internal UUID that links you to your API keys, credit balance, and verification records.

2.2 Billing data

When you buy credits, we retain the Paddle transaction ID, the Paddle customer ID, the pack purchased, and the number of credits granted. Your card number, CVV, and billing address are handled directly by Paddle — we never see them.

2.3 Email verification requests

When you submit an email for verification through our API, we process the address to produce a result. We do not retain the plaintext email address after processing. Our verification log stores:

• A SHA-256 digest of the normalized email address. This is a one-way identifier used for correlation and minimization, but common addresses may still be susceptible to dictionary matching; it is not encryption or anonymization.
• The domain portion only (e.g., gmail.com).
• The verdict (deliverable / undeliverable / risky / unknown) and signals array.
• Whether the result came from cache, the response time, and the timestamp.
• The API key ID that made the request.

The cache in Redis is keyed by SHA-256 of the address as well, and the cached value has the plaintext email field blanked out before storing. This means that even our in-memory cache does not contain readable email addresses.

2.4 IP verification requests

When you submit an IP address, we normalize and process it to return network and reputation information. For valid public IPs, our verification log stores a keyed HMAC of the normalized address—not the plaintext IP—plus its IP version, scope, ASN, organization, country, score, risk, blocklist outcome, signals, response time, timestamp, and the API key ID that made the request. Private, reserved, loopback, link-local, CGNAT, and otherwise non-routable addresses are not persisted as individual verification records.

The lookup may query reverse DNS and third-party DNS blocklists. DNSBL outcomes may be cached for up to 15 minutes. ASN, country, and Tor exit-node information is obtained from local datasets described in our service documentation. Reputation data is a time-bound signal and is not used to identify a natural person.

2.5 Phone verification requests

When you submit a phone number, we normalize it to E.164 and process it to produce a result. We do not retain the plaintext number in the verification log. For each verification the log stores:

• A keyed HMAC of the normalized number (not the number itself).
• Country and calling code, line type, carrier name, and mobile network codes (MCC/MNC), when available.
• The verdict, score, WhatsApp-presence estimate, and the reasons and flags behind them.
• The network status returned by a live line status query, when you requested one.
• Whether the result came from cache, the response time, the timestamp, and the API key ID that made the request.

To obtain carrier information we send the number to Telnyx. Only when you request the live line status option do we also send the number to Neutrino API, which queries the mobile network and returns whether the line is registered and reachable, whether it was ported, whether it is roaming, and network names. This query does not place a call or send a message to the subscriber. We do not request or store subscriber identifiers such as the IMSI. The raw carrier metadata returned by a provider (which does not include the phone number) is kept only 30 days.

If you use the phone blacklist feature, we store a keyed HMAC of each number you add, plus the optional note you write, linked to your API key, until you remove it or your account is deleted.

Short-lived cache entries in Redis are keyed by the HMAC of the number, never by the number: a basic validation marker (1 hour), carrier lookup results (up to 48 hours), and live line status results (a few minutes). They contain network metadata, not the plaintext number.

2.6 Bulk verification requests

For email, IP, and phone bulk jobs, we temporarily retain the submitted list and generated result file so that the job can be processed and downloaded. For phone jobs, the retained list and result file can contain the normalized phone numbers in plaintext, together with their keyed hashes. Bulk inputs, result metadata, and files are removed after the job retention period expires. Webhook URLs and secrets are also cleared when the job expires.

2.7 API usage

We keep server logs of API requests (IP address, User-Agent, endpoint, status code, duration) for debugging and abuse prevention. Logs live in the operating system journal on our server and are rotated automatically.

2.8 What we do not collect

• No third-party analytics on the API surface (api.byebouncer.com).
• No advertising trackers on any surface.
• No cookies on the marketing site beyond what is strictly necessary to run the login session.
• No behavioral profiling.

3. Legal basis (GDPR)

For visitors in the European Economic Area, our legal bases are:

• Contract (Art. 6(1)(b)) — to provide the API, authenticate you, and bill your usage.
• Legitimate interest (Art. 6(1)(f)) — to prevent abuse (rate limiting, fraud detection), operate the platform reliably, and improve reliability.
• Legal obligation (Art. 6(1)(c)) — to retain billing records as required by tax law in Paddle's jurisdictions and ours.

4. Sub-processors

We rely on the following processors, each with adequate data protection safeguards (Standard Contractual Clauses or equivalents where applicable):

If we add or replace a sub-processor, we will update this list before the change takes effect.

5. Retention

• Individual email verification records (digest + domain + verdict), individual IP verification records (keyed HMAC + result metadata), and individual phone verification records (keyed HMAC + result metadata): 90 days from creation, then deleted by a scheduled purge. The raw carrier metadata attached to a phone record is cleared after 30 days.
• Email result cache entries in Redis: 1 hour maximum. Cached DNSBL outcomes used by IP verification: up to 15 minutes. Phone cache entries: a basic validation marker up to 1 hour, carrier lookup results up to 48 hours, and live line status results a few minutes.
• Phone blacklist entries (keyed HMAC + optional note you provide): until you remove them or your account is deleted.
• Bulk inputs and result files: available for up to 7 days after the job reaches a terminal state, then removed by the scheduled cleanup process.
• Credit transactions (billing ledger): kept for the duration of the account plus 7 years, as required by tax and accounting regulations.
• Account data (email, hashed password, user profile): kept while your account is active. Deleted within 30 days after account closure, except billing records preserved for the reason above.
• Server logs: rotated automatically by the operating system journal, kept for approximately 30 days.

6. Your rights

Depending on your location (GDPR in EEA/UK, CCPA in California, LGPD in Brazil, similar laws elsewhere), you have some or all of the following rights:

• Access — request a copy of the personal data we hold about you.
• Rectification — correct inaccurate data (mostly you can do this in the dashboard).
• Erasure — request deletion of your account and associated data (subject to legal retention).
• Portability — receive your data in a machine-readable format.
• Objection — object to processing based on legitimate interest.
• Withdraw consent — where processing was based on consent.
• Lodge a complaint with your local data protection authority.

To exercise any of these rights, email hello@byebouncer.com from the address associated with your account. We do not charge a fee and aim to reply within 30 days.

7. International transfers

Our sub-processors are located primarily in the United States and the European Union. Data transfers outside the EEA rely on Standard Contractual Clauses or equivalent safeguards published by the destination processor. You can request copies of the relevant agreements.

8. Security

We take reasonable steps to protect the data we process, including:

• TLS 1.2+ enforced on all connections.
• API keys stored only as SHA-256 hashes; the plaintext value is shown once and never persisted server-side after creation.
• Passwords bcrypt-hashed by Supabase Auth.
• Row-level security (RLS) enabled on all database tables so each user can only reach their own data.
• Least-privilege systemd hardening on the backend process (no root, read-only filesystem except one data path, restricted syscalls, memory quota).
• Rate limiting and anti-abuse controls.
• Automatic security patching of the underlying operating system.

No system is perfectly secure. If we ever suffer a breach affecting your data, we will notify affected users without undue delay and, where applicable, notify the relevant supervisory authority within 72 hours as required by GDPR Art. 33.

9. Children

ByeBouncer is not directed to children under 16. We do not knowingly collect data from children. If you believe a child has provided us data, please contact us and we will delete it.

10. Cookies

The dashboard uses HTTP cookies strictly necessary to keep your login session (issued by Supabase Auth). These cookies are HttpOnly and Secure. We do not use tracking, advertising, or analytics cookies on any of our surfaces.

11. Changes to this policy

We may update this policy from time to time. Material changes will be announced by email to account holders and on the dashboard at least 15 days before taking effect. The “Effective date” at the top always reflects the current version.

12. Contact

Privacy questions and requests: hello@byebouncer.com.