Integration touchpoints
Edge is configuration-driven by design: most implementations never call a platform API directly. The integration surface you work with is your Salesforce org and your tenant configuration. This page summarizes the touchpoints that exist and where each one is documented.
For how these touchpoints are secured — authentication, encryption, tenant isolation — see Architecture & Security.
Salesforce REST endpoint (Edge Pay)
Edge Pay communicates with your org through a REST endpoint exposed by the Kaptio managed package:
salesforce:
rest_endpoint: /services/apexrest/edge/payments
The platform calls this endpoint to read payment context (schedules, amounts, itinerary status) and to write payment results back to the itinerary. You configure the endpoint path and the extra fields it may read in payment.yaml; the gateway routing record in your org is covered in Salesforce integration.
Document viewer links
Every generated document is delivered as a secure viewer URL — the {{viewerUrl}} binding available in email templates. Viewer links:
- are signed per tenant and expire according to your blueprint's
securityandviewer_lifecyclesettings, - render expiry and superseded-version banners using the wording you configure under
document_validity, - require no authentication from the guest beyond possession of the link — see Security model: public document and payment page access for how link signing prevents tampering.
Lifecycle configuration is covered in Blueprint: document actions & email.
Generation triggers
Documents are generated two ways:
| Trigger | Configured in | Example |
|---|---|---|
| User action | create_document_actions | A sales agent clicks "Create Proposal" on an itinerary. |
| Automatic | auto_generated_documents | A booking confirmation generates and sends when a booking is confirmed; a financial summary generates when a payment is received. |
Both are configuration, not API calls — see Document types.
Eligibility queries
Payment eligibility rules in payment.yaml run SOQL against your org at payment time (for example, blocking payment unless the itinerary is in Option or Booked status). These are declared in configuration and reviewed with Kaptio during onboarding — see the payment.yaml reference.
Booking APIs (Edge Journeys)
Edge Journeys exposes a full booking API — catalog, baskets, pricing, promotions, payments, and checkout — for tenants building their own booking frontends or agent-driven flows. This is the largest programmatic surface on the platform:
- API architecture — layers, authentication, tenant isolation
- Journeys API reference — every endpoint with request/response examples
- Data model — the domain objects and their platform mapping
- Platform API surface — the underlying KTAPI, Basket Service, and Edge Composite surface available beyond the wrapper
Edge Connect
Kaptio connects to third-party supplier services through one stable contract. Edge Connect provides the connection point for a growing catalog: it serves new native adapters directly and passes established connectors through to Kaptio Connect without changing their requests.
- Edge Connect overview: one connection point, catalog growth, and established-connector continuity
- Available connectors: connector families, product coverage, and connection models
- Performance and reliability: session reuse, duplicate protection, reconciliation, and eligible response caching
- Edge Connect architecture: request routing, state, credentials, cutover, and rollback
- Booking lifecycle: search, reserve, book, retrieve, amend, cancel, and reconcile
- Onboarding a supplier: how a new connector joins the catalog
Programmatic checkout (advanced)
E-commerce checkout sessions and card-tokenization flows (quote acceptance with card-on-file) exist as capabilities in the platform and ship in the baseline as disabled stubs. They involve per-tenant endpoint and webhook provisioning, and are enabled with Kaptio during implementation. If your project needs web checkout integration, raise it with your implementation team — the configuration shape is shown in the payment.yaml reference.