Onboarding a supplier

A new connector joins the Edge Connect catalog through a repeatable, fixture-first delivery path. Kaptio builds from the supplier's documented contract, verifies the result against its test environment, and activates it for one tenant at a time.

The process is designed to turn complete supplier inputs into a verified connector in weeks rather than a bespoke integration project measured in months. Actual timing depends on documentation quality, supplier responsiveness, test access, capability scope, and acceptance results.

This page explains what is needed from you and the supplier, what Kaptio builds, and how the connector reaches go-live.

What you need to provide

Kaptio needs both documentation and access, but not always at the same time.

Input	What it should include	When it is needed
API documentation	Endpoints, operations, authentication, request and response fields, error codes, session behaviour, rate limits, and any caching restrictions	Before connector design starts
Schema and message samples	OpenAPI, WSDL, XSD, JSON Schema, example XML or JSON, and representative success and error responses	Before implementation starts
Test credentials	A non-production account with the products and permissions needed to exercise the agreed lifecycle	Before live verification
Test data	Search dates, product codes, traveller combinations, and any known request-only or unavailable cases	Before scenario testing
Supplier contact	A technical contact who can answer contract questions and investigate test-environment issues	Throughout implementation and verification
Network requirements	IP allowlists, client certificates, VPN requirements, or permitted origins	Early, because external changes may have lead time
Production credentials	The production account, supplied through an approved secret-sharing channel	Before production activation

Do not paste credentials into project documents, email threads, tickets, or configuration files. Kaptio will arrange a secure provisioning path.

What can start before credentials arrive

Implementation can begin when the supplier has provided a complete contract and representative sample messages:

1. Kaptio models the supplier's operations and response types.
2. The supplier samples become sanitized test fixtures.
3. Parsers, serializers, and field mappings are built against those fixtures.
4. Error, session, and unsupported-capability behaviour is tested locally.
5. The adapter is connected to the common Kaptio booking contract.

Credentials are still required before Kaptio can prove that the documentation matches the supplier's live test service. Documentation without credentials therefore supports development, but not acceptance or go-live.

Step 1: agree the lifecycle

Before implementation, Kaptio and the tenant agree which supplier operations are in scope:

• product and availability search,
• reservation or hold,
• booking confirmation,
• retrieve,
• amendment quote and confirmation,
• cancellation quote and confirmation,
• content import,
• reconciliation.

The supplier's capabilities are mapped against the common booking lifecycle. Gaps are made explicit. For example, a supplier may support immediate booking but no temporary hold, or it may return cancellation policy text without a separate cancellation-quote operation.

Step 2: build fixture-first

Kaptio builds the protocol layer from sanitized supplier examples before making live calls.

Fixture tests verify:

• request messages match the supplier's schema,
• successful responses parse into typed data,
• application errors and transport faults remain distinguishable,
• optional and repeated fields are handled,
• credentials and guest data are absent from committed fixtures.

This gives the connector a repeatable contract test suite and lets most implementation proceed without depending on the availability of the supplier test service.

Step 3: map to the Kaptio contract

The supplier-specific operations are then mapped to the stable Edge Connect contract. This includes:

• product, rate, currency, and availability mapping,
• supplier booking references and statuses,
• cancellation and amendment policies,
• errors and request-only states,
• session renewal,
• duplicate-submission protection,
• eligible caching and reconciliation services.

The adapter must return explicit unsupported or unavailable results where the supplier contract has no equivalent operation. It does not fabricate prices, references, or confirmations.

Step 4: verify in the supplier test environment

With test credentials provisioned into the encrypted secret store, Kaptio runs the agreed scenarios against the supplier:

1. Log in or establish a supplier session.
2. Search for the supplied test products and dates.
3. Create and confirm a test booking.
4. Retrieve the booking from the supplier.
5. Amend it where supported.
6. Cost and confirm cancellation.
7. Confirm the final supplier status and clean up the test data.

Failures are traced across the Kaptio request, Edge Connect, the adapter, and the supplier response. Any discrepancy between the written documentation and observed behaviour is recorded and resolved with the supplier.

Step 5: tenant acceptance

Technical verification proves the protocol. Tenant acceptance proves the business workflow.

Acceptance scenarios should include:

• the products and destinations used at go-live,
• the required traveller and room combinations,
• confirmed and request-only inventory,
• sold-out or unavailable responses,
• the expected amendment and cancellation policies,
• duplicate submissions and recoverable session expiry,
• changes made in the supplier portal and reconciled into Kaptio.

The same scenarios should be retained as regression coverage for future connector changes.

Step 6: activate per tenant

The connector ships without changing every tenant's routing. Activation is controlled per tenant:

1. Production credentials are provisioned securely.
2. The tenant's agreed smoke scenarios are run in the target environment.
3. The tenant's connectivity route is switched to Edge Connect.
4. Success rates, latency, and supplier errors are monitored.
5. The previous route remains available for immediate rollback during the canary period.

Other tenants are unaffected by the activation.

Readiness checklist

Supplier inputs

• API documentation is current and complete.
• Schemas and representative success and error samples are available.
• Test credentials are provisioned securely.
• Test products, dates, and scenarios are confirmed.
• A supplier technical contact is named.
• Network allowlisting or certificate work is complete.

Connector verification

• Fixture tests cover every in-scope operation.
• The adapter passes the common contract tests.
• The full booking lifecycle succeeds in the supplier test environment.
• Errors, session renewal, and duplicate submissions are tested.
• Tenant acceptance scenarios pass.
• Production credentials are provisioned securely.
• Cutover and rollback owners are confirmed.

Related pages

• Edge Connect overview
• Available connectors
• Edge Connect architecture
• Performance and reliability
• Booking lifecycle
• Security model