Rental & vehicle sharing

Settle the scratch at the counter, not by email three weeks later.

A check-out inspection and a check-in inspection, both captured on a phone, both anchored to the same part map — so the difference is a set of parts instead of an argument.

Rental desks, car-sharing operators and anyone handing over keys at volume

Today

The customer says the scratch was already there. The agent says it wasn’t. Nobody photographed that panel at check-out.

What changes

  • Two inspections in one schema, keyed to the same parts, timestamped at both handovers.
  • A report the customer can look at, with the damage pinned on the car instead of described in a paragraph.
  • Tire wear graded on its own, because it bills differently from a dented door.

Where it starts

One endpoint, before you commit to anything.

Both ends of the rental run the identical call. The Capture SDK walks a customer or an agent through a complete shot set, so the evidence exists before the dispute does.

the first call

per vehicle

POST/v1/inspections

model: the bundle — eight stages

async by default · webhook or poll · independently rate-limited

The chain

The flow that first call sits in.

Each row is a real endpoint, priced and rate-limited on its own. Call one, call the set, or let /v1/inspections chain them for you.

  1. 01
    Capture SDK

    Layer 1 component

    A non-expert is walked through the shot set — the piece nobody wants to build twice

  2. 02
    POST/v1/video/onboard

    video-onboarding · per video

    One walkaround, indexed into frames by position, at both handovers

  3. 03
    POST/v1/parts/decompose

    parts-decomposition · per vehicle

    The same component map on both inspections — this is what makes them comparable at all

  4. 04
    POST/v1/damage/detect

    damage-detection · per image

    Damage located and typed on each pass, keyed to those parts

  5. 05
    POST/v1/damage/severity

    severity-estimation · per detection

    Fair wear separated from something you would actually charge for

  6. 06
    POST/v1/pricing/repair

    reparation-pricing · per vehicle

    A number per new damage, against your rate card rather than a fixed fee schedule

  7. 07
    POST/v1/viewer/hotspots

    viewer-hotspoter · per image

    Each damage anchored on the vehicle, tappable in the report you show the customer

Across the stack

What this path draws on, layer by layer.

Layer 1 · Components

all →
Capture SDK
Camera flow that guides a non-expert through a complete shot set, start to finish
Review SDK
Human-in-the-loop validation and correction of model output
Report SDK
Composed condition report, customer-branded, web or export
Player SDK
Embeddable 360° inspection viewer — drops into your own site against a tokenised report URL

Layer 3 · Data

all →
Identity
VIN decode, build sheet, factory options, plate → VIN lookup
Specs
Technical data, equipment, dimensions, powertrain
Parts
OEM references and catalogues — feeds pricing/repair

Where it goes

Then the same key runs the fleet

Disputes are the reason you integrate. What accumulates afterwards is a condition record per VIN that the rest of the business turns out to want.

  • Keyless handover

    plate-reader opens and closes the loop with no agent present

  • Your fair-wear policy, encoded

    severity-estimation thresholds and tire-detection carry your rules instead of a desk agent’s judgement

  • Condition over time

    Inspections accumulate per vehicle, so degradation is a curve rather than an anecdote

  • Remarketing

    The final inspection renders listing imagery when the car leaves the fleet

What we do not claim

There is no “compare two inspections” endpoint, and we would not trust one that hid its arithmetic. What the platform guarantees is that both inspections carry the same part decomposition and the same damage schema — the delta is a set difference over part IDs, computed by your rules, in your system.

Start with /v1/inspections

One call, on your own data, before anything in your product changes.