API integration
You build the experience.
We work on
the engine.
For appropriately FCA-authorised firms and Appointed Representatives that want to own the interface, an API integration provides a route to the comparison capabilities underneath.
More control
comes with more ownership.
The API approach suits teams with the engineering capacity to design, integrate and maintain their own customer experience.
Your interface
Pages, forms, accessibility and frontend behaviour
Yeti Engines
Comparison orchestration and provider integration
Participating insurers
Quote responses and the route to purchase
Start with the contract
between the systems.
A technical workshop establishes what the integration must do. The detailed API specification follows the agreed scope.
- Inputs & responses
- Required fields, quote eligibility, returned cover information and the presentation requirements for the customer journey.
- Session & state
- How the experience manages progress, incomplete quotes, expiry, retries and returning customers.
- Failure behaviour
- How the interface handles unavailable providers, validation errors and incomplete responses.
- Security & environments
- Authentication, credentials, access, test data, environment separation and release responsibilities.
- Attribution & operations
- Event definitions, commercial identifiers, logging, monitoring, change communication and support ownership.
Regulatory model
API integration is intended for firms that are appropriately FCA authorised in their own right or operating as an Appointed Representative with permissions covering the activities performed through the integration.
It is not offered as a route for Introducers or Introducer Appointed Representatives to collect or process customer quote information. Where a partner wants to own the interface and customer-data collection, the regulatory model must be agreed with IRL before technical scoping and launch.
Let’s scope the integration.
API access and its launch scope are agreed with partners. We’re not presenting a public, self-service API or promising that every proposed capability is available today.
Security and delivery considerationsA few useful answers.
Can we keep our existing frontend?
Potentially. We review its journey, data model and integration requirements to determine what can be retained and what needs to change.
Can we bind a policy through the API?
The initial proposition is quotes, comparison results and insurer click-out. Quote-and-bind may be available as a later extension, subject to the required insurer, operational and regulatory arrangements and separate approval before launch.
Is there a public API reference?
We’ll work through the proposed integration and share the applicable technical material during the scoping process. There is no public API reference or access-key sign-up on this site.
Bring your product team.
We’ll talk through the experience you want to own and what the engine needs to provide.