BUL — Privacy Policy
Last updated: October 9, 2026
1. Who and what
BUL is operated by Avi Friman. Contact: support@friman.app.
BUL (bul.friman.app) is an Email API service. Businesses and organisations ("customers") use it to send transactional email and campaigns to their recipients, and to receive delivery reports. This policy explains what data BUL processes, why, where, for how long, and who it is shared with.
2. Two kinds of data
- Data the customer sends through the service — message content, recipient addresses and the related events (delivery, open, click, complaint, opt-out). BUL processes this data on the customer's behalf and on its instructions. The customer is responsible for the legal basis for collecting it and for sending. A recipient who wants to exercise a right (access, correction, deletion) should contact the sender. Requests that reach BUL are forwarded to the relevant customer, and BUL helps the customer respond.
- Data about the customer and its use of BUL — the account, users, security, abuse prevention, audit logs and product use. BUL processes this data for its own purposes, to run and secure the service.
3. What data, and why
| Data | Why |
|---|---|
| Account and users: account name, user emails, role, password (hash only), second factor, last sign-in, acceptance of the terms (which version and when) | Running the service, permissions, security |
| Domains and DNS checks | Sender verification, abuse prevention |
| API keys (hash and prefix only) | Authenticating requests |
| Messages: recipient, sender, subject, Reply-To, headers, tags, content (HTML / text), attachments | Sending, and showing and reporting to the customer |
| Events: delivered, bounced, opened, clicked, complained, unsubscribed | Reporting, honouring opt-outs, protecting reputation |
| Opens and clicks: IP address, User-Agent, and the owner of the IP (ISP or organisation) | Telling human from automated opens, and reporting. The customer can turn click tracking off |
| Suppression list (address and reason) | Not sending again to an address that bounced, complained or opted out |
| Webhooks: endpoint URL and delivery log | Real-time reporting to the customer |
| Security and audit: sign-ins, permissions, account actions, IP, country, User-Agent; sign-up attempts (IP hashed only) | Security, investigation, abuse prevention |
| Reputation data: aggregate delivery statistics per domain | Protecting deliverability |
BUL does not sell data, does not use message content for advertising, and does not use it to train AI models.
4. How long data is kept
| Data | Retention |
|---|---|
| Message content (HTML, text, inline attachments) | 30 days from message creation |
| Attachments | 30 days from upload; a preview copy, up to 30 days from the last view |
| Events (including IP and User-Agent for opens and clicks) | 90 days, after which only daily counts without recipient details remain |
| Message record (recipient, sender, subject, headers, tags, status, timestamps) | As long as the account exists |
| Webhook delivery log | 90 days |
| Suppression list | Until the customer removes an entry. An entry caused by the recipient opting out, a complaint or an address that doesn’t exist is kept for as long as the account exists, to honour the recipient’s wishes |
| Account, users and API keys | As long as the account exists |
| Security records (sign-ins, permissions, identification and authentication, access and security events) | 24 months |
| Other audit log entries (settings changes and account actions) | 12 months |
| Records of automated system actions | 180 days |
| Sign-up attempts | 90 days |
| Verification, reset and invitation links | 30 days after use or expiry |
| Sending-server logs (recipient, sender, receiving server's reply) | 30 days |
| Technical server logs | Rotated by size — days to weeks |
| Send queues (a copy of the message until it is sent) | Up to 4 days |
| Records of BUL's internal AI agents (no recipients and no content) | Currently no time limit |
| Encrypted backups (including all of the above) | Up to about 35 days |
5. Account deletion
- Account owners request deletion from the dashboard (Settings → Delete account). The account is frozen immediately, and there are 7 days to cancel.
- Data in active systems is deleted within 30 days of the request. An email is sent when the request is received, and another when deletion from active systems is complete.
- Backups are deleted according to the backup cycle, within about 35 days; they are not deleted immediately.
- What is kept after deletion — narrowly, and documented:
- the account's security records (sign-ins, permissions and security events, including the record of the deletion request) — until the end of their 24 months;
- addresses that bounced, complained or opted out — only as a one-way hash together with the sending domain, for up to 24 months. This way, deleting an account does not lead to future sending from the same domain to an address that asked not to receive email. The address itself is not kept and is not disclosed to anyone;
- the deletion request record (when, and by whom);
- information the law requires us to keep, such as invoices, once they exist.
- Our sending provider keeps its own suppression list of addresses that bounced or complained, to protect deliverability.
6. Providers that process data for BUL
This is BUL's complete list of subprocessors (updated 12 October 2026).
- Amazon Web Services — email sending (Amazon SES), job queues and delivery events, in the Israel region (il-central-1). Two separate accounts in the same region: one for customers BUL onboards, and one for self-service customers.
- Supabase — the database, in the European Union (Germany). (Updated 11 October 2026; previously Ireland.)
- OVHcloud — BUL's application servers and sending server, in Germany.
- Cloudflare — DNS, attack protection, storage of attachments and encrypted backups (R2, in European data centers), the status page and uptime monitoring (Workers — no personal data), sign-up form protection (Turnstile), and receiving support email and sending alerts to BUL's team (Email Routing).
- Team Cymru — identifying the owner of an IP address in open events (ISP or organisation). Receives only the IP address, with no email address and no content.
- Google — Sign in with Google (only the email address and the Google account ID are stored), Google Postmaster Tools (see section 7), and the mailbox that receives support requests.
- Anthropic — the AI model behind BUL's internal operational agents. The agents make recommendations to BUL's team and do not take actions. They receive structured data only:
- account ID and name;
- sending domains;
- event counts for the last 24 hours;
- structured mail-server error codes (without the full reply text);
- trust level and sending limits;
- recent automated action types;
- infrastructure status: queue, backups and processes.
They do not receive recipient addresses, email content, subjects, headers or attachments.
- rdap.org and public DNS services — checking DNS records and the age of a sending domain. They receive only the domain name.
Some data is stored and processed outside Israel (in the European Union, and by providers that also operate in the United States). BUL chooses providers that commit to appropriate safeguards. A Data Processing Addendum (DPA) is available on request.
7. Google Postmaster Tools
- Access. BUL connects to the Google Postmaster Tools API with read-only access (postmaster.traffic.readonly), through the Google account of BUL's operator. It uses this access only to monitor the sending reputation of domains that send through BUL and are verified in Postmaster Tools.
- What is read: aggregate, domain-level data:
- spam complaint rate;
- SPF, DKIM and DMARC authentication success;
- encryption;
- delivery errors;
- Gmail sender requirements compliance status.
- What is not read: BUL has no access to mailboxes, messages or Gmail users' personal details.
- Why: to show reputation in the dashboard to the customer who owns the domain, and to slow down or pause sending when reputation drops, to protect deliverability.
- What we don't do: the data is not sold, not transferred to third parties, not used for advertising, and not used to train AI models.
- Storage and revocation: the authorization token is encrypted with AES-256-GCM. Access can be revoked at any time at myaccount.google.com/permissions.
- Limited Use: BUL's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
8. Security
- Encryption in transit: all traffic to the service is encrypted with TLS (HTTPS). Delivery to recipient mail servers uses TLS whenever the receiving server supports it.
- Customer isolation: each customer can see only its own data (Row-Level Security in the database).
- Secrets and hashing: secrets are encrypted with AES-256-GCM. API keys and tokens are stored as hashes only.
- Backups: encrypted before they leave the server, and locked against deletion.
- Admin access: only over an encrypted private network, with keys.
- Monitoring: real-time monitoring and alerts.
In a security incident, BUL will act and notify as the law requires.
9. Cookies
- The dashboard uses a strictly necessary sign-in cookie only.
- There are no advertising cookies and no tracking or analytics cookies.
- Cloudflare may set technical security cookies.
10. Your rights
- Customers can ask to access, correct or delete their data. Account deletion is done from the dashboard, as described in section 5.
- A recipient can unsubscribe using the link in the message, or contact the organisation that sent it.
- Requests: for any privacy question, write to support@friman.app.
11. Changes
When this policy changes, the update date changes. Material changes are sent to customers by email and shown in the dashboard. Previous versions are in the version history.
