Security & database access

Sendly reads customer data straight from your database so your marketing team never exports spreadsheets. This page is written for the engineer or IT administrator who has to say yes to that. Everything below describes how the product actually behaves.

1. What Sendly accesses

• Read-only, always. The database user you create for Sendly needs SELECT only. Sendly additionally parses every statement before it runs and refuses anything that is not a plain SELECT — INSERT, UPDATE, DELETE, DROP, SELECT … INTO, FOR UPDATE, stored-procedure calls and writes hidden in CTEs are all rejected before reaching your server.
• Only what you grant. You choose the scope: structure only (table and column names, no rows), just the tables Sendly needs with sensitive columns excluded at the database level, or the whole database. Sendly generates the exact GRANT statements for MySQL/MariaDB, PostgreSQL and SQL Server.
• What it looks for: your customers table (email, name, signup and activity dates), and the tables that describe what customers did — orders, payments, subscriptions, appointments. It never reads columns that look like passwords, tokens, card numbers or national IDs, even if granted.

2. How it connects

• One fixed IP. All connections to your database come from a single static address: the IP shown in your dashboard. Whitelist that one address and nothing else.
• Encrypted in transit (TLS where your server offers it) and credentials encrypted at rest with AES-256-GCM, a random IV per value, keys held outside the database.
• Private addresses are refused. Sendly will not connect to loopback, link-local, cloud-metadata or RFC-1918 addresses — protection for you and for us.
• Every query has a hard execution timeout (default 60 s; scan probes 20 s), enforced on the connection (MAX_EXECUTION_TIME / statement_timeout / request timeout). A slow query can never hang your database.
• Read replicas welcome. If you run RDS/Aurora, Cloud SQL or a readable secondary, point Sendly at the replica endpoint — zero load on production.

3. What happens to the data

• Sendly runs aggregate and segment queries on demand and caches the results for 15 minutes per account. It stores email addresses and names of the customers you email (that is what a campaign is), plus delivery events (sent, opened, clicked, bounced).
• It does not copy your database. Row-level data outside a campaign's recipients is not retained.
• Schema information (table and column names) from the last scan is kept so segments can be rebuilt without rescanning.
• Deleting your account deletes the stored connection, scans, segments, campaigns and recipient data within 30 days; you can request immediate deletion.

4. Tenant isolation

Every account (tenant) is isolated at the data layer: every query against Sendly's own database is scoped by tenant, credentials are decrypted only for the requesting tenant, and a regression suite runs on every change to prove one tenant cannot read, modify or trigger actions on another's data. Platform-admin access is a database flag that can only be granted by an operator, never derived from an email address.

5. Query log

A per-account log of every statement Sendly runs against your database — with timestamps and durations — is being added so your team can audit exactly what was read. Until it ships, ask us and we will provide the log on request.

6. Compliance

• Nigeria Data Protection Regulation (NDPR) and the Nigeria Data Protection Act 2023
• South Africa POPIA · Ghana Data Protection Act 2012 · Kenya Data Protection Act 2019
• GDPR for European data subjects
• A signed Data Processing Agreement is available on request; the template is public.

7. Reporting a security issue

Email [email protected]. We acknowledge within one business day and will notify affected customers of any confirmed breach within 72 hours.

Quick answers for IT

Question	Answer
Can it write to our database?	No. SELECT-only user, and a parser that refuses anything else.
Which IP do we whitelist?	One static address, shown in the connection wizard and in the invite email your colleague sends you.
Do we have to expose production?	No — use a read replica, or grant structure-only access first and widen later.
Which tables does it need?	Customers plus the tables that record what customers did. After a structure-only scan Sendly generates a grant limited to exactly those.
Where is it hosted?	DigitalOcean; email delivery via Resend; optional AI mapping via DeepSeek (schema names only, sample values masked).