Skip to main content
Onboarding a dealership takes three calls: check that the site is supported with Resolve Dealership, start the setup with Setup Dealership, then poll Get Setup Status until inventory is ready.

Step 1 — Resolve the dealership

Before setting anything up, ask the resolve endpoint whether the site is supported and whether it already exists on your account. This call is fast and free of side effects — nothing is created.
The two fields that decide your next move: You can also resolve by dealer_name + vin, by vin alone, or by dealer_name + dealer_address — see the endpoint reference for the full matrix and how ambiguous matches (LOW_CONFIDENCE_MATCH, DEALER_GROUP_DETECTED) are reported.

Step 2 — Start the setup

Setup is asynchronous: the call returns HTTP 202 with a setup_id in well under a second, and detection plus configuration run in the background.
If the dealership was previously deleted from your account, the same call reactivates the existing subscription instead — that path returns HTTP 200 with the completed result inline, and there is nothing to poll.

Step 3 — Poll for status

Poll the status endpoint with your setup_id every 5 seconds until it resolves:
Two fields matter, in sequence:
  1. status — the setup lifecycle: pendingrunningcompleted (or failed, with an error field explaining why).
  2. inventory_statusstatus: "completed" means the dealership is configured, not that vehicles are ready. Keep polling until inventory_status is "available", then call Fetch Inventory.
Prefer push over polling? Subscribe to the setup.complete and import.complete webhook events before calling setup — import.complete fires the moment the first inventory import lands.

How long does setup take?

Setup time is dominated by provider detection — fetching the dealer’s site, identifying the platform, and validating the configuration. Typical times by platform, from recent production setups: Heavily bot-protected sites can take up to ~10 minutes regardless of platform — that’s the upper bound before a setup fails with a timeout. These numbers are averages, not guarantees; always drive your client off status and inventory_status, never a fixed wait.

The whole flow in one script