Your app knows the market.
Now let it read the vehicle.

With the ULTRA adapter connected, your app can read the VIN directly from the vehicle, so staff do not have to type it or photograph a door-jamb label. Whether the VIN comes from the vehicle or from your own system, it can be decoded into the specifications the source returns: model year, make, model, engine and, where available, trim, body class, drive type and equipment details.

The decoded record is what ties every later finding to the right vehicle. It describes how the vehicle was built, not how it is now: a decoded engine code says nothing about whether that engine has a fault today.

Modern vehicles are run by many electronic control units (ECUs), or modules: engine, transmission, anti-lock brakes, airbag/SRS, body control, instrument cluster, infotainment and others, all talking over in-vehicle networks. When a module detects a problem it stores a diagnostic trouble code (DTC).

A generic OBD-II reader is built around emissions-related powertrain codes. CarDr's OEM-level scan uses manufacturer-specific protocols through ULTRA to query the additional modules a vehicle supports, so transmission, ABS/braking, airbag, body and network faults can appear in the same result.

The first letter of a DTC names a system family: P for powertrain, B for body, C for chassis and U for network communication. It is a family, not a single module: a U code can be stored by the radio, the ABS module or the instrument panel. Each result is therefore reported with the module that stored it.

A raw code such as P0442 tells a technician where to look; it means little to an appraiser or a buyer. CarDr's cloud interprets each code in the context of the vehicle, the module that stored it and its status, and returns a description of the fault, the affected system and, where supplied, its likely impact.

Context matters because manufacturer-specific codes can mean different things on different makes. The same code read without the vehicle can be misleading.

For each interpreted code, repair intelligence can return a criticality rating, a commonality classification, the components or parts most likely involved with a parts quantity, a parts cost range, a labor hours range, a labor cost range, an overall repair range and an impact statement. CarDr's reports present these per code alongside a headline total repair estimate.

Criticality describes how important or severe the finding is. Commonality is a classification of how often the fault is seen (for example Common or Uncommon); it is not a numeric probability of failure. The listed parts are the components a repair commonly involves, not a confirmed list of what this vehicle needs; a technician's diagnosis decides that.

Resting battery voltage is part of every CarDr scan report. With Cold + Warm Scan, the Cold Scan runs with the ignition on and the engine off, capturing resting battery voltage and the ECU baseline; the Warm Scan runs with the engine running and confirms which faults persist. One merged report separates voltage-sensitive codes from persistent faults.

This matters because a weak 12-volt supply can cause modules to set communication and voltage codes that disappear once the battery is charged. Seeing voltage next to those codes helps a reviewer decide whether to recharge and rescan before treating them as repairs.

Clearing codes erases stored faults and resets emissions monitors, so a vehicle can look clean right after a reset. Where the vehicle reports them, CarDr shows the counters that follow a clear, such as distance and warm-up cycles since codes were cleared, alongside monitor readiness, and flags whether a recent reset was found.

A recent reset is a reason to look closer: rescan after a drive cycle, or inspect the systems involved. It is not proof of wrongdoing; codes are routinely cleared after legitimate repairs and battery work.

Vehicles run self-tests called readiness monitors on emissions systems such as the catalyst, evaporative system, oxygen sensors, EGR and fuel system. Each monitor is complete, incomplete or not supported on that vehicle. Recently cleared codes or a disconnected battery leave monitors incomplete until the vehicle is driven enough.

Live data streams current values from selected parameters the vehicle supports, such as engine speed or coolant temperature, as timestamped entries while your app is connected. Freeze frame data is different: it is the snapshot of values a module stored at the moment a specific code was set.

Together they help a technician reproduce an intermittent fault during a test drive and understand the conditions when a code first appeared.

Recall campaigns are issued for groups of vehicles, typically by year, make and model. Whether a particular VIN still has an open, unrepaired recall is a separate, VIN-specific question.

CarDr's full diagnostic reports include recall information. Which recall data is available to your integration, and whether it is VIN-specific open-recall status or campaign-level context, is confirmed during integration scoping.

Each completed CarDr scan produces a dated report. Keeping those reports associated with the VIN and your inventory or work-order record lets your team pull up an earlier inspection, attach it to a deal, or compare the findings from before and after service.

Your app can also keep its own record of each scan entry it receives through the SDK. How completed reports are retrieved from CarDr for your integration is defined during scoping.

Some products need the finished document: a scan summary report with the vehicle, findings, cost ranges, emissions readiness and reset indicators that can be shared by link or PDF. Others need structured results to render in their own interface. CarDr supports branded report delivery, and the format your integration receives is agreed at scoping.

The SDK can clear generic codes or all codes on supported vehicles, with a progress callback for the full clear. This belongs in service workflows, after a fault has been diagnosed and repaired, and only when a user explicitly asks for it.

Clearing does not fix anything. It erases stored evidence, resets emissions readiness monitors, and can trigger the reset indicators described above. Some codes, such as permanent codes, are not erased by a clear and only go away after the vehicle verifies the repair.

The SDK connects to an ULTRA adapter over Bluetooth, reports connection-state changes and disconnections, and publishes scan progress and the scan type as a scan runs, along with interim scan updates. A scan entry records whether it started and completed, so your app can tell a finished scan from one that was interrupted.

Firmware updates can be started from the app with progress reporting, optionally targeting a specific version or release level.

For auctions, CarDr offers an Arbitration Risk Flag shown with the scan and a separate, more detailed Arbitration Risk Report. The flag helps route a unit at check-in, for example toward a closer inspection or disclosure, while the report explains the findings behind it.

Both are optional products. Whether and how they are available inside your integration is confirmed during scoping.

CarDr TrueCost turns the scan into an acquisition decision inside the OBDIQ app: severity-ranked repairs with cost estimates, live wholesale and retail market data, all-in cost, and a BUY / CAUTION / PASS verdict on the appraisal — plus a customer-facing trade-in offer view.

TrueCost is live in beta in OBDIQ. Integration access, data delivery and market coverage are confirmed with CarDr during scoping; the beta does not imply an undocumented API contract.