Security

How Peakbeat is secured

What the system does today, in plain terms. We do not claim any certification.

Last updated 13 October 2026.

Read-only access to your systems

• Peakbeat calls a fixed list of Salesforce B2C Commerce endpoints: list and read orders, list sites, and the order search. The order search is a POST that changes no data. Any other call is refused in our code before it is sent.
• Each retailer has its own call budget. When it is used up, Peakbeat stops calling.
• The API client we ask you to create has read access only, and you can remove it at any time.

Fixed addresses for your allowlist

All calls to your systems leave from a small set of fixed IP addresses, so you can allow exactly those and no others. The worker that makes the calls checks its outbound address before it starts and about every minute after. If the check fails, it stops calling your systems until it passes.

Credentials

• API secrets are encrypted before they are stored, with a separate key per retailer, wrapped by a master key.
• The web servers hold no key. They can store a new secret but cannot read one back; the web service refuses to start if given the master key. Only the background worker can decrypt a secret, and only to make the call.
• A saved secret is never shown again; the console shows only that one is set.

Separation between retailers

Every row of data carries its retailer, and the database enforces row-level security on it. A request is bound to one retailer and the database refuses rows from any other, whatever the application asks for. The web service, the worker and the owner console connect as different database roles, each with only the permissions it needs.

People and access

• Retailer users sign in with Salesforce Account Manager, or with a one-time link sent to their email. Peakbeat stores no passwords for retailer users.
• Roles (admin, ops, care, viewer) decide what a person can see and change. Customer email is limited to care and admin.
• The platform owner has a separate sign-in with a salted scrypt password hash. A platform owner is never an Account Manager user.

Sessions

• A session is a random token in a cookie that is HttpOnly, SameSite=Lax and Secure on https. The database stores only a hash of the token.
• Retailer sessions last 12 hours and owner sessions 8 hours. Signing out ends the session at once.
• Role changes and removals take effect on the next request. A suspended or closed retailer is paused.
• Email sign-in links are valid for 15 minutes. Opening a link only shows a page; the sign-in happens when the person presses the button, so mail scanners do not use it up.

Audit

Changes to a retailer's settings are versioned and logged with who made them and when. Every action by the platform owner on a retailer is logged with a reason and kept for 7 years. Both logs are append-only: the database refuses edits and deletions, except for clean-up after the retention period and the removal of a closed retailer's data.

Hosting, backups and recovery

• Peakbeat runs on servers we operate, not a public cloud.
• The database is backed up continuously so it can be restored to a chosen point in time, and is replicated to a standby server.
• Report email leaves from our own mail server, with unsubscribe headers and bounce handling.

Report a vulnerability

Email admin@gautamlab.com with the details and how to reproduce it. We will acknowledge it, keep you informed, and fix confirmed issues. Please do not access data that is not yours, and give us reasonable time to fix before you disclose it.

For what we store and for how long, see the privacy page.