Welcome to our new Vignette ID Developer Portal documentation!
How to start

Order Flow

A read-once reference for partners building any integration with Vignette ID. This page maps the moving parts (your backend, our API, the national provider, your webhook endpoint) to the events they exchange so you can wire your system correctly the first time.

If you only have five minutes, skip to the sequence diagram β€” it shows the full happy path from POST /orders to the PDF confirmation.


Choose your integration

We support three integration shapes. Pick one based on how much UI control you need vs. how fast you want to ship.

PathBest forTime to liveCustomization
APIEstablished partners with their own checkout2–6 weeksFull
WidgetTravel sites, content sites, MVP launches1–3 daysTheme + presets
IframeAffiliates, blogs, no-code sites< 1 hourLocale + theme

End-to-end order flow

A robust integration is shown as one timeline: pre-flight checks, then bounded-retry order creation, then the async lifecycle driven by webhooks. Status names match /wiki/statuses; webhook events match /wiki/webhooks.

Why each step matters

  1. GET /products/status on page load β€” country and period availability can flip mid-day (national provider outage, maintenance window). Run this before rendering the form, not at submit time, so unavailable countries / durations are hidden in your UI rather than "click to find out". Cache the response for ~60 s β€” there's no reason to hammer the endpoint on every page hit.
  2. POST /validate-vehicle after the user enters the plate β€” catches typos (Cyrillic chars, malformed VINs, missing dashes for AT/DE) on the cheap server-side check before spending an order attempt. Failed validation costs nothing; a failed POST /orders costs an idempotency slot and can leave a partial record. Run it on form submit (or onBlur of the plate field for inline UX).
  3. POST /orders outcomes:
    • 200 β€” keep the returned id, persist it locally, then watch webhooks.
    • 409 (or equivalent duplicate signal) β€” stop trying. Re-querying with the same body will produce the same answer. Surface the existing order to the user.
    • 5xx / network errors β€” transient. Retry once per minute, max 5 attempts (β‰ˆ5-minute total window). After that, surface a "we couldn't process your order" screen and notify on-call.
    • 4xx other than 409 β€” your request is malformed (bad plate format, invalid product). Don't retry; fix the input.

Idempotency and duplicates

Sending the same POST /orders body twice during a network blip can create two orders. Use an idempotency key (or compare against your local "in-flight" record) before retrying β€” every retry should include the same key as the first attempt so the API can deduplicate.

Failure & cancellation paths


Status reference

Every status you'll see in webhook payloads or GET /orders/{id}/status:

StatusWhen you see itWhat to show the user
CREATEDRight after POST /orders succeeds"Processing your order…"
DEFERREDStart date > 3 days from purchase"Vignette scheduled for <date>"
PENDINGAwaiting national provider"Processing your order…"
WILL BE ACTIVEProvider registered, awaiting unique ID"Almost ready…"
ACTIVEVignette is valid β€” user can drive"βœ… Vignette is active"
EXPIREDValidity period ended naturally"Expired on <date>"
REFUNDEDCancelled or charged back"Refunded"
DELETEDUnknown error, contact supportShow error + support link

Full descriptions and cancellation windows: Statuses list.


Don't poll β€” listen for webhooks

GET /orders/{id}/status is rate-limited to 15–25 req/min per order ID (rate limits) precisely because polling is the wrong tool here.

Recommended

Configure your webhook URL in the Partner Panel and update your local order record on every ORDER_STATUS_CHANGED. Use GET /orders/{id}/status only as a manual fallback (e.g. an admin "refresh" button).

Webhook payload format and signature verification: Webhooks.


Next steps

Last modified on