Axle for Platforms

​

What is a platform?

• Our platform partners are typically software providers that provide many services to their customers, and want to offer Axle as a feature or add-on of their platform.
• For example, a dealership management system might be a platform with many dealerships as customers.
  • These dealerships want to use Axle to verify insurance information for their own users, but may not want to setup Axle themselves.
  • As they are already accustomed to using certain systems, it will be easier for them to use Axle if it is embedded into those systems.

​

How does a platform use Axle?

In the Axle system, a platform’s customers are referred to as destination clients. The platform is responsible for onboarding destination clients to Axle, and then can make requests to Axle’s APIs on behalf of the destination client.

Platforms can configure a new destination client using the POST /platform/clients endpoint. This will return a unique id for your new destination client, which the platform should store in their database alongside their internal unique identifier for the destination client, because it will be used to authorize requests to Axle’s APIs on behalf of the destination client.

Platforms should integrate Axle into their product or service using the process outlined in Axle’s Quickstart guide. The only major difference is that in addition to providing the x-client-id and x-client-secret headers to authorize each request, the platform should also provide the destination client id in the additional x-destination-client-id header.

​

Onboarding a destination client

​

Capture interest in Axle

Setup a landing page or self-service mechanism to capture interest in instant insurance verification through Axle by your customers, partners, or any other dependent services.

​

Register a destination client with Axle

Once a service has expressed interest in leveraging Axle, use the POST /platform/clients endpoint to register it as a new destination client.

When registering a new client, you’ll be asked for the following information:

• displayName: A human-friendly name for the destination client. This will be used in Ignition and in the Axle dashboard.
• entity: A url-friendly name for the destination client. These must be unique in the Axle system, so it is recommended to use a combination of your platform’s name and the destination client’s name.

Store the destination client’s id in your database alongside your internal unique identifier for the destination client. This will be used to authorize requests to Axle’s APIs on behalf of the destination client.

If you do happen to lose the destination client id, you can retrieve it using the GET /platform/clients endpoint to get a list of all destination clients registered with your platform.

​

Make requests on behalf of destination client

You can now authorize requests to Axle’s APIs on behalf of this destination client by providing the x-destination-client-id header. The following endpoints can be authorized on behalf of the destination client:

For more details and advice about how to integrate these API calls with your service, please see the Quickstart guide.

​

Handle redirect, Window MessageEvent, or webhook Ignition events

All events include a client parameter with the destination client id, so you can easily associate an event with the correct destination client. Please refer to the guides on Ignition events and Account or Policy events for more details.