Platform architecture
This page describes how the Edge platform is built and hosted, for teams evaluating Edge as part of a technical or security review. It complements the product-specific documentation elsewhere on this site — Edge Docs, Edge Pay, Edge Journeys, and Edge Webforms — with a system-level view.
What Edge is
Edge is a multi-tenant platform that turns the bookings, itineraries, and pricing in your Salesforce org into branded documents, payment experiences, booking journeys, and enquiry intake — driven by your tenant configuration rather than custom code written for your account. See How tenants work for the configuration model.
Key architectural characteristics
- Multi-tenant, shared platform code. All tenants run on the same application services; what differs between tenants is configuration (and, for Edge Journeys, tenant-owned frontend source), not separate platform deployments per customer.
- Salesforce org ID determines tenant. When a request originates from your org, the platform resolves your org's registered ID to your tenant configuration. See How your Salesforce org connects.
- Configuration and application code are separated. Your tenant configuration (YAML, JSON Schema, Handlebars templates) is deliberately independent from the platform's application code. Configuration changes are reviewed and merged through your own workflow and take effect without any platform deployment. See How changes ship.
- Cloud-hosted, containerized services. The platform runs as a set of containerized services on Google Cloud Platform, orchestrated with Kubernetes (GKE), in the EU (
europe-west1). - Separate production and staging environments. Each environment is a fully separate deployment with its own infrastructure. Your org is registered against exactly one environment at a time (see tenant model), and sandbox orgs can be pointed at a staging environment independently of production.
Platform services
Edge is composed of a small number of services, each with a single responsibility. No service other than the integration gateway communicates with Salesforce directly.
| Service | Responsibility |
|---|---|
| Integration gateway | The only service that talks to Salesforce and Kaptio's core API layer. Handles OAuth/session management, tenant resolution from your org ID, and reads your tenant configuration from its source repository. |
| Editing tools | Internal tools your team (or Kaptio, on your behalf) uses to preview and edit document content before it is sent, and to author payment/webform configuration. |
| Render engine | Renders validated document data through your Handlebars templates to produce the document your recipient sees. |
| Viewer | Serves the public, unauthenticated document viewer described in Delivery, viewer security, and tracking. |
| Payment | Serves the branded payment pages described in Edge Pay. |
| Journeys | Serves tenant-owned booking-experience frontends described in Edge Journeys. |
| Webforms intake | Receives and processes website enquiry submissions, described in Edge Webforms. |
| Preferences | Serves the customer-facing preference portal used from Edge Docs viewer links. |
How data flows
Every product on Edge follows the same shape: Salesforce is the system of record, your tenant configuration decides what happens with the data, and the platform renders and delivers the result.
- A user action in Salesforce, a recipient opening a signed viewer or payment link, or a website posting a webform submission triggers a request. Salesforce-initiated traffic carries your org ID; guest links carry a tenant-scoped signature; webform traffic carries per-tenant API credentials.
- The integration gateway resolves the request to your tenant, loads your configuration, and — where the operation requires it — queries your org over an authenticated connection.
- The appropriate service (render engine, payment, journeys, or webforms intake) processes the request using your configuration and returns a document, payment page, booking step, or form response to the guest or agent.
- Results (a rendered document, a payment result, a booking, a qualified enquiry) are written back to your org through the same gateway.
For the product-specific version of this flow, see Edge Docs: how a document is produced, Edge Pay: the payment flow, and Edge Webforms: the intake pipeline.
Configuration storage and delivery
Your tenant configuration is stored in a Git repository, independent of the platform's application code. The platform reads your configuration and caches it briefly for performance; a merge to your configuration's production branch is live within minutes, without any platform deployment. See How tenants work and Owning your configuration for the full model, including the option to manage your configuration repository directly.
Where to go next
- Security model — authentication, secrets, encryption, and tenant isolation
- Data handling — what data Edge processes and where it resides
- Payment security — how card data and payment credentials are handled
- Security FAQ — quick answers for a security questionnaire