The short version
- Without an account, nothing reaches us at all.
- Signing in stores your email, your flows and your saved connections so they work across devices and can run on a schedule.
- Credentials are masked before a run is recorded, at the moment of writing rather than when a screen is drawn.
- There is no analytics, no advertising and no telemetry of any kind.
- You can export everything, and delete everything, at any time, without asking us.
Signing in
Authentication is by emailed sign-in link. There is no password — which means there is no password database to leak, no reused credential to be stuffed, and nothing for you to rotate if another service is breached.
Authentication and database hosting are provided by Supabase. Access is enforced by row-level security, meaning the database itself refuses to return one account's rows to another account, rather than relying on the application to remember to filter.
Credentials
A connection holds the credentials for one service — a webhook URL, an API key, a bot token. When you use Zymura signed out, those stay on your device. When you sign in, they are stored in our database, because a server cannot authenticate to Slack or GitHub on your behalf without them. That is a real trade-off and worth stating plainly rather than glossing over.
Credentials are sent only to the service the step names — Slack to Slack, Telegram to Telegram. They are not read, analysed or transmitted anywhere else.
Masking in run history
Run history records what each step received and returned, which is the only way to see why something failed. Before a run is written, two passes run over it:
- Fields a connector has declared secret are replaced with a mask.
- Values matching the shape of a known credential — the recognisable formats used by common services — are masked wherever they appear, including inside response bodies.
The honest limitation. Shape matching is best-effort. A credential in an unusual format, buried in a response body, may not be recognised. If a flow handles something you would not want recorded at all, run it in the app rather than on the server.
Code steps and the server
Zymura has a Code connector for writing a few lines of JavaScript when a step is easier expressed that way. Those steps run in your browser only.
The server refuses to execute dynamic code at all. The runtime blocks it at the platform level, so user-supplied JavaScript is never compiled or run server-side. This is a limitation of the product — a Code step will not work on a scheduled flow, and the designer warns you when you try — but it is also the reason there is no sandbox to escape from and no path from a flow into our infrastructure.
The request proxy
Browsers block many direct calls to third-party APIs. With the proxy setting on, a step's request is forwarded through our server and the response returned to you. The proxy does not write request or response bodies to storage and does not log them. It refuses cross-origin callers and requests aimed at private network addresses.
You can switch the proxy off in Settings, in which case requests go directly from your browser and never reach us.
What is kept, and for how long
| Data | Where | Retention |
|---|---|---|
| Email address | Supabase, Mumbai | Until you delete your account |
| Flows and connections | Your device, and Supabase if signed in | Until you delete them |
| Run history from the app | Your device only | Last 300 runs |
| Run history from the server | Supabase, Mumbai | 7 days Free · 90 days Pro · 1 year Team |
| Webhook payloads | Cloudflare KV | Collected on arrival, expire after 3 days |
| Operational logs | Cloudflare | 30 days |
| Database backups | Supabase | Cycled within 90 days |
Deleted accounts are erased rather than archived. There is no shadow copy and no soft-delete flag.
Who else processes your data
| Provider | What they handle | Where |
|---|---|---|
| Cloudflare | Hosting, scheduled execution, the request proxy, the webhook queue | Global edge network |
| Supabase | Authentication and the database | Mumbai, India |
| Dodo Payments | Checkout, invoicing and tax, as merchant of record | Only if you buy a paid plan |
No others. Beyond these, the only external services contacted are the ones your own flows name. We never see or store card details — the payment provider handles them, and we receive only your plan, its status and your billing country.
What we don't claim
Plenty of services display security badges that mean less than they appear to. Here is what Zymura does not have, stated plainly so you can judge for yourself:
- No SOC 2 or ISO 27001. Both require an external audit over a sustained period. Zymura has not been through either, and displaying a badge implying otherwise would be dishonest.
- No service level agreement. On any plan. Scheduled flows are checked on a five-minute cycle and may be delayed by a few minutes.
- No penetration test report. None has been commissioned.
- No SSO, audit log or enterprise controls.
What is true is that the underlying infrastructure — Cloudflare and Supabase — is operated by companies that do hold those certifications, and that the design deliberately keeps the sensitive surface small: no password store, no telemetry, no dynamic code execution on the server, and masking applied before data is written rather than before it is shown.
Reporting a vulnerability
If you find a security problem, please email support@zymura.app with enough detail to reproduce it. Reports are read personally and taken seriously.
Please give a reasonable opportunity to fix an issue before disclosing it publicly. There is no paid bounty programme — Zymura is a small operation and cannot fund one honestly — but credit is given gladly to anyone who wants it.
Related reading. The privacy policy covers your rights, lawful bases and jurisdiction-specific detail. The terms set out responsibilities on both sides. Deleting everything is described on the account deletion page.