Legal

Security Disclosure

Notifiable stores the data required to deliver notifications for your apps. This page explains the controls we use, and how to tell us if you find a problem.

Last updated October 11, 2026

What we protect

Your workspace holds account details, app configuration, subscriber devices, notification content, and the secrets that make delivery work. We keep that data inside your workspace. Another customer who asks for it receives a not-found response, not a confirmation that it exists.

Sign-in

A magic link is single-use and expires in 15 minutes. We email the token and store only its SHA-256 hash. Opening the link consumes it. Signing in starts a new session. Signing out invalidates that session.

The session cookie is HttpOnly, so page scripts cannot read it, and it uses SameSite Lax. Forms in the dashboard are protected against cross-site requests. GitHub, Google, and Apple sign-in are accepted only when the provider returns a verified email.

Workspaces and roles

An app belongs to one workspace. Members have a role. A viewer can look. Changing delivery, resetting keys, sending a notification, and inviting people require a developer, an admin, or the owner. Billing is limited to the owner.

Keys and secrets

A public key identifies an app and an environment. It can register a device and record an event. It cannot send a notification. Resetting it replaces that key. Clients still holding the previous key can no longer identify themselves.

A server API key can send. The full secret is shown once, when you create it. We store a SHA-256 hash, not the secret. You can set an expiration and a request limit, and you can revoke the key. An expired, revoked, or over-limit key is rejected.

Apple signing keys, push credentials, webhook secrets, and provider keys you save are encrypted before they are stored. The Apple signing key is not shown again after it is saved. Card numbers are collected by Paddle and are not stored by Notifiable.

Delivery

The site, the dashboard, and the API are served over HTTPS. Push to Apple and Google uses those platforms’ authenticated channels. A Web Push payload is encrypted before it is sent to the browser’s push service. A dead device token is marked invalid so we do not keep retrying a destination that can no longer receive the message.

Webhooks

When Notifiable calls a webhook you configure, the request is signed so you can confirm it came from us. A disabled endpoint receives nothing. Stripe and RevenueCat can start an automation only after the incoming webhook signature checks out.

What this page is not

These are the controls the product uses today. This page is not a certification, a penetration-test report, or a promise that a breach is impossible. If a control changes, this page will change with it.

Report a problem

If you believe you have found a vulnerability, write to [email protected] with a description, the URL or endpoint involved, and the steps to reproduce it. Give us a chance to fix it before you publish the details.

Please do not access another customer’s data, destroy data, or interrupt the service while you investigate. We will not take legal action against research that stays within those bounds and that you report to us in good faith. Do not include a live server API key or a signing key in the first message if you can describe the issue without it.

Ready to send?

Your app users one notification away.

Connect your app and send your first Notification in minutes.