Axle for Platforms

​

What is a platform?

Our platform partners are typically software companies that provide many services to their customers, and want to offer Axle as a feature 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 customers, but may not want to setup Axle themselves. They’re already acccustomed to using a certain dealership management system, so we want to make it easy for them to use Axle through that system.

​

How does a platform use Axle?

In the Axle system, we refer to a platform’s customers 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 information 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/client 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 we recommend using 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 /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 core APIs on behalf of this destination client by providing the x-destination-client-id header. The following routes 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 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 our guide on Ignition Status Handling for more details.