Skip to main content

Security model

This page describes how Edge authenticates users and systems, protects credentials, isolates tenants from one another, and controls access to public documents and payment pages.

Authentication​

Two distinct mechanisms secure the platform, for two different purposes.

Sessions initiated from Salesforce​

When a user in your org opens a document action, payment link, or other Edge-initiated flow, Salesforce issues a signed session token scoped to that action — the itinerary, the tenant, and the acting user. The token is signed with a secret unique to your tenant and validated by the platform before any data is loaded or rendered. A token cannot be replayed against a different tenant's configuration, and it does not grant broader access than the specific action it was issued for.

Platform access to your Salesforce org​

All platform access to your org's data goes through a single integration gateway — no other Edge service connects to Salesforce directly. The gateway authenticates using OAuth 2.0, with the authorization code flow (PKCE) used for the initial connection during onboarding. Once established, the connection is used to read the data your configuration's queries request, and to write back results (document status, payment outcomes, form submissions).

Secrets and credential management​

  • Secrets never live in your configuration files. Payment gateway credentials, signing keys, and API keys are stored in the platform's encrypted secret store and referenced from configuration as vault:: keys (for example, vault::braintree_public_key). The configuration repository's automated validation rejects any literal credential committed by mistake.
  • Secrets are provisioned by Kaptio, not authored by your team, and are scoped per tenant — one tenant's secrets are never usable against another tenant's configuration.
  • Your Salesforce OAuth connection credentials are encrypted before being stored by the platform; they are decrypted only at the point of use by the integration gateway.

Encryption​

  • In transit: all traffic between your Salesforce org, your recipients' browsers, and Edge services is encrypted (HTTPS/TLS).
  • At rest: OAuth connection credentials and other stored secrets are encrypted in the platform's database, using a key that is itself never stored in your tenant configuration or committed to any repository.

Tenant isolation​

  • Routing. Tenant context is established before any configuration is loaded or org data is queried. Salesforce-initiated requests are resolved from your registered org ID; guest viewer and payment links are resolved from the signed, tenant-scoped link itself; webform intake is resolved from per-tenant API credentials. In every case, one tenant's configuration, signing secrets, and gateway credentials cannot be used to serve another tenant's request.
  • Configuration. Your tenant configuration is a self-contained folder (or, for self-managed teams, an entire dedicated repository — see Owning your configuration). It cannot reference or read another tenant's files.
  • Credentials. Signing secrets, gateway credentials, and OAuth connections are all provisioned and scoped per tenant.

Public document and payment page access​

Recipients of a document or payment link are not required to authenticate — this is by design, since guests do not have Salesforce accounts. Access is instead controlled by the link itself:

  • Viewer links are signed and time-limited. The link that reaches a recipient is cryptographically signed per tenant; it cannot be guessed or constructed by a third party. The underlying access token is short-lived, while the link itself remains valid for a configurable number of days, independent of the document's business expiry — see Delivery, viewer security, and tracking.
  • Expired and superseded documents are locked out. After a document's configured validity window, the viewer replaces the content with a contact call to action rather than continuing to serve the original content.
  • Payment pages are similarly link-scoped, and additionally gate on real-time eligibility rules checked against your org before any payment form is shown — see Edge Pay overview.

Change control​

Every change to your tenant configuration — document templates, payment rules, branding, webform mapping — goes through the same controlled path: a merge request, automated validation (syntax, schema, and test-harness checks), and a review gate before it reaches production. See How changes ship and, for self-managed teams, Owning your configuration. This gives every configuration change an auditable history and a required review step, whether Kaptio or your own team authors the change.

Payment-specific security​

Card data handling, PCI scope, and gateway credential management are covered separately in Payment security.

Questions this page doesn't answer​

For compliance certifications, data retention policy, subprocessor lists, and other items that require confirmation from your account team rather than a technical description, see the Security FAQ.