Edge Connect architecture
Supplier connectivity has one stable entry point and two execution paths. Kaptio sends the same booking contract to Edge Connect whether the supplier is served by a native adapter or by an established connector in Kaptio Connect.
End-to-end request path
One Kaptio contract, with routing selected behind the Edge Connect boundary.
The path has four layers:
| Layer | Responsibility |
|---|---|
| Salesforce | Starts the user workflow and remains the system of record for the itinerary. |
| KTAPI | Converts the Kaptio action into the common supplier contract and returns the normalized result. |
| Edge Connect | Authenticates the request, resolves its tenant and supplier, and selects the native or pass-through path. |
| Supplier adapter | Translates the common contract into the supplier's protocol and maps the response back into the Kaptio contract. |
Native and pass-through routes
Native supplier route
A native adapter communicates directly with the supplier. It owns the supplier-specific details: message envelopes, authentication sessions, field mapping, error interpretation, and booking references.
The adapter does not change the contract seen by KTAPI. Supplier protocols can differ — REST, SOAP, XML, or JSON — while Kaptio receives one consistent response shape.
Kaptio Connect pass-through
If a supplier does not have a native Edge adapter, Edge Connect passes the request to Kaptio Connect. The pass-through path preserves the method, request path, query string, body, contract-relevant end-to-end headers, and upstream status. It removes transport-specific headers that must not cross a proxy boundary, does not reinterpret the supplier request, and does not retry it.
Kaptio Connect therefore remains supported and continues to serve its established connectors behind the facade. The architecture introduces no forced migration date for those adapters. See Available connectors for the current provider families and SPI paths.
Why the native path is on Edge
New adapters are built on Edge for specific architectural reasons:
| Reason | Effect |
|---|---|
| Room for performance services | One native boundary lets Kaptio add session reuse, duplicate protection, reconciliation, and eligible response caching per connector. |
| One code and test boundary | Supplier protocol types, mappings, fixtures, state, and reconciliation evolve together. |
| AI-assisted engineering | Sanitized message fixtures and strict contract tests give engineering agents a bounded protocol-to-response task that humans can review and verify. |
| Operational correlation | Native requests use the Edge logging, metrics, and tracing path from facade request to supplier response. |
| Incremental rollout | One tenant and supplier can move without changing the route used by other tenants or established connectors. |
A native Edge adapter and an established direct Kaptio Connect adapter have the same high-level gateway-to-supplier shape. The native path is not positioned as faster because it removes a hop. Its advantage is the single implementation boundary where Kaptio can introduce and measure performance services without changing the Kaptio client contract.
Performance and reliability explains how session reuse, duplicate protection, reconciliation, and supplier-specific caching are applied.
How contract parity is protected
The facade is only safe if it behaves like the connection point it replaces. Contract replay tests enforce this.
- Representative request and response pairs are captured and sanitized so they contain no credentials or personal data.
- Each pair is replayed through Edge Connect against a controlled upstream response.
- The test compares the status, content type, headers, and response body with the recorded contract.
- A difference blocks release until it is understood and accepted.
Native adapters add a second layer of tests: supplier fixtures are parsed and mapped into the same common contract. This separates two questions:
- Does the facade preserve the Kaptio contract?
- Does the adapter correctly implement the supplier protocol?
Both must pass before a connector can be activated.
Supplier state
Some supplier operations span multiple requests. The Edge Connect native-adapter design defines the minimum state needed to make those operations reliable:
| State | Purpose |
|---|---|
| Supplier session | Reuses a valid supplier authentication session and renews it when it expires. |
| Booking record | Links the Kaptio session and itinerary item to the supplier's booking reference and latest status. |
| Idempotency record | Returns the stored result when the same booking action is submitted again, avoiding duplicate supplier bookings. |
| Reconciliation cursor | Records how far a periodic supplier update check has progressed. |
When a native adapter uses this state, every record includes tenant context. Reads and writes are scoped to that tenant before supplier state is accessed.
Credential handling
Supplier credentials are provisioned into Kaptio's encrypted secret store. An adapter receives only the credentials for the tenant and supplier handling the current request.
Credentials and supplier session tokens:
- do not live in tenant YAML or Salesforce records,
- do not appear in application logs,
- do not pass through to the browser,
- are not shared between tenants.
The Salesforce configuration carries non-secret information used to select the connector, while the secret values stay in the platform vault.
Per-tenant cutover and rollback
Cutover changes the supplier-connection base URL used for one tenant. It does not require a managed-package change or a different Salesforce data model.
The rollout sequence is:
- Run fixture and contract tests in continuous integration.
- Verify the connector against the supplier's test environment.
- Exercise the agreed booking scenarios for the tenant.
- Point that tenant's supplier traffic at Edge Connect.
- Monitor request success, latency, and supplier errors.
Other tenants continue using their existing route. If the canary identifies an issue, the tenant's base URL can be returned to the previous connection point immediately.
Observability
Edge Connect assigns a correlation identifier to each facade request. The foundation emits structured logs and bounded metrics for route groups, status classes, and duration without recording credentials or guest details.
This identifies routing and upstream failures on the facade path. Native adapters add supplier-operation context as they are activated, allowing support teams to distinguish mapping, session, availability, and supplier API failures.