26 platforms, inside your AI
Zomler
Back to Zomler

Security

Last updated July 21, 2026

How Zomler protects data, and how to report a vulnerability. We would rather hear about a problem from you than from an incident.

Zomler holds two kinds of sensitive material: information creators authorise us to receive from platform APIs, and the credentials that make that possible. This page describes how both are protected and how to tell us when something is wrong.

01Reporting a vulnerability

Email security@zomler.com. Include enough detail to reproduce the issue — a URL, a request, or a short proof of concept. If you would rather encrypt it, say so in a first message and we will send a key.

  • We acknowledge within 3 business days and tell you whether we have reproduced it.
  • We aim to fix critical issues within 7 days and everything else within 90.
  • We will not pursue you for good-faith research that respects the boundaries below.

Please do not access, modify or delete data belonging to anyone else, degrade the service for other people, or use social engineering or physical attacks. Test against your own account. If you access someone else's data by accident, stop and tell us — that report is welcome, and the honesty matters more than the finding.

02How data is protected

  • In transit: TLS 1.2 or higher everywhere. Our origins reject plaintext HTTP, and calls to platform APIs are HTTPS-only.
  • At rest: data is stored in managed Postgres with encryption at rest enabled. Access tokens are never written to logs and are never returned by any endpoint.
  • Access: production data is reachable only by named accounts with multi-factor authentication, on the code repository, the deployment pipeline and the database console alike. Access is reviewed and revoked when someone no longer needs it.
  • Separation:data received from a platform API under a creator's authorisation is stored separately from public information, so the two can never be silently mixed by a query.
  • Least privilege: the public web application holds no database credentials. Every write goes through an internal API that authenticates the caller first.

03Logging and monitoring

Application events are logged with a timestamp, the acting identity and the outcome, and retained for at least 30 days. Logs are structured so that unusual patterns — repeated authorisation failures, unexpected spend, a provider behaving differently — surface as signals rather than as something noticed later.

Access tokens, API keys and secrets are excluded from logs by construction rather than by redaction after the fact.

04If something goes wrong

If we discover a breach affecting personal data we will notify affected people and the relevant authorities without undue delay, and in any case within 72 hours of becoming aware where the law requires it. Where platform data is involved we will also notify the platform, as their developer terms require.

We will tell you what happened, what data was involved, and what we changed. A notification that omits the third part is not worth sending.

05Contact

Security: security@zomler.com · Privacy: support@zomler.com