Move photos without handoffs
Send a vehicle photo, start a processing step, retrieve the finished result and notify your system without repeating work by hand. REST v1 covers the headless path; signed webhooks, in-app exports and phone capture complete the workflow that is live today.
https://vehiclephoto.com/api/v1Live surfaces
What works today
REST v1 accepts scoped bearer keys. You can verify a key, ingest a public image URL or multipart upload, start one recipe step for a known image, and retrieve a known photo or job by ID. The machine-readable OpenAPI document is public at /api/v1/openapi.json, so request and response shapes can come from the live contract instead of a copied example.
Completion webhooks remove the need to poll every job. Register an HTTPS callback with a key carrying the webhooks scope; the endpoint secret is shown once. Each delivery includes a timestamp and a lowercase hexadecimal HMAC-SHA256 signature over the timestamp plus the raw body, giving your receiver a concrete verification step before it trusts the event.
Bulk export runs inside the signed-in app after photos are approved. Select the channel profiles you need and package the available processed photos into a ZIP. The response also carries a manifest that records the included files and the export choices, which makes a handoff easier to inspect before anything is uploaded elsewhere.
Phone capture begins on a signed-in computer and hands the session to a phone through a QR code. The short-lived link keeps the phone inside the same capture session, accepts original uploads, and returns the completed listing to the account. It is a browser handoff, so there is no separate capture app to install.
Delivery is export-based today. Syndication connectors and direct DMS push are not live, so use the ZIP and manifest or retrieve signed results through REST v1, then send those files with the destination workflow you already control. That boundary keeps the documented integration aligned with the product you can use now.
Authentication
Use one scoped key
Sign in, then mint a key in API keys. Copy the secret when it appears because it is shown once.
Choose only the scopes the connection needs: ingest sends photos, process starts a recipe step, read retrieves known photos and jobs, and webhooks manages completion callbacks. A smaller scope set limits what a copied key can do.
Send the one-time secret as Authorization: Bearer <KEY> on every REST request. Keys are resolved to one account boundary, can be revoked from the same screen, and never replace the signed-in session used by in-app ZIP export or the desktop side of phone capture.
Treat the secret like a password. Keep it in a server-side secret store, never put it in browser code or a public repository, and rotate it by creating a replacement before revoking the old key.
Setup
Connect your client
- Step 1
Create a scoped key
Open API keys after signing in, give the key a recognizable name, select the scopes required by your workflow, and copy the secret when it is shown.
- Step 2
Verify the key
Call GET /api/v1/ping with the bearer header and confirm that the returned account boundary and scopes match the connection you intended to create.
- Step 3
Send one photo
Call POST /api/v1/ingest with a public image URL or multipart bytes. Keep the returned image and vehicle identifiers because processing and retrieval are deliberately ID-based.
- Step 4
Process and retrieve
Submit the image ID with one recipe step to /api/v1/process, poll the returned job by ID, and use its signed result URL before that URL expires.
- Step 5
Choose the handoff
Register a signed completion webhook when a system should react automatically, or use the signed-in bulk export screen when a reviewed ZIP and manifest are the better operational handoff.
Verify a key
curl --request GET https://vehiclephoto.com/api/v1/ping \
--header "Authorization: Bearer <KEY>"Ingest by URL
curl --request POST https://vehiclephoto.com/api/v1/ingest \
--header "Authorization: Bearer <KEY>" \
--header "Content-Type: application/json" \
--data '{"imageUrl":"<PUBLIC_IMAGE_URL>","vin":"<VIN>"}'Boundaries
Know the limits
Each bearer key receives 60 authenticated requests per 60-second window. A refused request returns HTTP 429 and a Retry-After header with the wait in seconds.
Ingest accepts one photo per request. URL ingest permits public HTTPS sources and refuses private, loopback, link-local or multicast destinations. Multipart uploads and the supported image formats and size ceiling are described in the OpenAPI document.
Processing accepts a known image ID and one recipe step per request. Retrieval is also ID-based; REST v1 does not publish inventory-wide list endpoints. Signed result URLs are temporary, so download the file rather than treating the URL as permanent storage.
Webhooks retry temporary delivery failures and sign every attempt with a fresh timestamp. Verify against the raw request body, compare signatures in constant time, reject stale timestamps, and make the receiver idempotent because a retry can repeat an event.
Sources
- https://vehiclephoto.com/api/v1/openapi.json — VehiclePhoto REST v1 OpenAPI 3.1 contract, including authentication, scopes, errors and webhook verification.
- https://vehiclephoto.com/admin/api-keys — The signed-in VehiclePhoto screen for minting, scoping and revoking bearer keys.
FAQ
Questions answered
Where is the OpenAPI file?
The live OpenAPI 3.1 document is at https://vehiclephoto.com/api/v1/openapi.json. It describes REST v1 authentication, request bodies, scopes, status codes and webhook signature verification.
Can REST v1 list everything?
No. The live surface works with known photo and job IDs. It can ingest, process and retrieve those records, but it does not publish inventory-wide list endpoints.
Can it push into a DMS?
No direct DMS push or syndication connector is live. The supported workflow is export-based today: retrieve signed results through REST v1 or create a reviewed ZIP and manifest in the app, then use your existing destination workflow.
How are webhooks verified?
Use the endpoint secret shown at registration to compute HMAC-SHA256 over the timestamp, a period and the exact raw body. Compare that lowercase hexadecimal value with x-vehiclephoto-signature and validate the accompanying timestamp.
Does phone capture need an app?
No separate app is required. A signed-in browser creates a short-lived QR handoff, and the phone opens a capture page tied to that session so the uploaded originals return to the same account.
Keep exploring