Skip to main content
Monitoring is not enabled by default. It requires user consent and must be enabled for your client to receive account and policy events. Please contact the Axle team if you would like to enable this feature!
1

Configure Ignition to receive webhooks

Ensure that the request made to generate an Ignition token includes the webhook URL where you would like to receive notifications.
Custom webhook headers can be configured to support uses cases like authentication. Please contact the Axle team if you would like to configure custom webhook headers!
Request Sample: cURL
curl --request POST \
  --url https://api.axle.insure/ignition \
  --header 'Content-Type: application/json' \
  --header 'x-client-id: cli_mZj6YGXhQyQnccN97aXbq' \
  --header 'x-client-secret: RZM-5BErZuChKqycbCS1O' \
  --data '{
    "webhookUri": "https://example.com/webhook",
    "user": {
      "id": "usr_xyz"
    }
  }'
Notifications can also be sent to your organization via other communication channels such as email or Slack. Please contact the Axle team to configure which events should be sent to each channel. All events will be sent via webhook if a webhookUri is provided.
2

Store `accessToken` for future access

The accessToken and account or policy you received via Exchange Token must be stored by your application to access updated Account or Policy objects.If a returning user links a new insurance account, a new access token will be returned. You should compare the new token against the one you have stored for this user and determine if the old access token needs to be de-scoped. See Descope Token for more details.Alternatively, if a returning user links the same insurance account, the same access token will be returned. This would re-connect a previously disconnected monitored account.
It is recommended to store the accessToken alongside your application’s user identifier. All Account and Policy events return the user.id specified when generating an Ignition token, so this will improve retrievability.If a user ID was passed into the user.id field during Start Ignition, and you want a historical timeline of all accounts a user has linked across entities, you should store a mapping of user, entity, and access token in your system.
3

Process Account and Policy events

Notifications will be triggered by the following events and will need to be processed by your application.
  • Account events
    • account.modified: Updates made to identifying details for the insurance account (e.g., name, email, phone)
    • account.disconnected: The account and any connected policies are no longer being monitored by Axle
  • Policy events
    • policy.modified: Updates made to insurance policy, such as policy cancellation or change in coverages
4

Retrieve Account or Policy object

For security, Account and Policy events do not include the entire Account and Policy objects, but include a ref to identify which Account or Policy is impacted by this event. You can retrieve the object via this identifier and the accessToken stored in your application.
Axle will continue refreshing the Account and Policy objects even if these events are not triggered. Refer to the refreshedAt date on the Account and Policy to determine when the data was last successfully retrieved from the insurance carrier.
5

Validate against requirements and contact user if action is required

policy.modified: Validate updated Policy against your application’s requirements. If policy does not meet requirements, ask user to complete new Axle Ignition session.account.disconnected: Ask user to complete new Axle Ignition session. See Account events for additional guidance on messaging.Key considerations:
  • If the user reconnects the same insurance account and policy, Axle will merge the updated information with any existing Account or Policy objects.
6

If needed, stop monitoring for user's `accessToken`

When monitoring is no longer required for a specific user or entity, such as when a loan is no longer being tracked or a driver is offboarded from a platform, you can de-scope monitoring from the accessToken stored for that user or entity. See Descope Token for more details.