UDS Evidence API

Capture first. Enrich later.

Register a source, associate it with a session, and save an observation backed by a source record. Vehicle identity, ECU family, manufacturer, transport and response may all remain unknown.

1. 01 / Capture

   Source + evidence

   What was observed

2. 02 / Store

   Message + session

   Immutable byte content

3. 03 / Interpret

   Interpretation

   Separate, unreviewed claim

API base

https://api.redlineautohaus.com/api/v1/uds

Contract

OpenAPI 3.1.2; read the active contract version and effective limits from authenticated GET /capabilities.

Public / private

Documentation is public. Dataset records, source artifacts and payload reads require authorization.

Authentication and scope

Create a key in your account settings and send it in Authorization: Bearer <token>. The server assigns ownership from the authenticated principal. Do not send a shop or scope identifier in a resource body.

Every active developer key automatically includes evidence submission in a private account workspace. Read the shared key guide. Normal ingestion requires uds:write; verification reads require uds:read. Review, administration, protected artifact access and sensitive identifiers have separate permissions. Ingestion credentials cannot mark a claim verified.

Every POST mutation requires an Idempotency-Key. Keep tokens in environment variables or approved secret storage; never paste them into a public example, URL or source capture.

Your first observation

1. Create a source describing its actual origin, including manual transcription when applicable.
2. Create a session and attach the source. Neither a vehicle nor an ECU is required.
3. Create a source record with a stable key and excerpt or locator.
4. Create an unknown-context message, then read it back and compare exact bytes.

{
  "session_id": "<returned session ID>",
  "source_record_id": "<returned source record ID>",
  "external_record_key": "observation-001",
  "client_namespace": "example.manual",
  "layer": "uds_pdu",
  "direction": "unknown",
  "payload": {
    "representation": "complete",
    "payload_hex": "22F186"
  }
}

Synthetic example; placeholders above are not valid IDs. The quickstart and runnable examples capture IDs returned by preceding requests.

Keep evidence and meaning separate

Canonical hex contains no spaces. Unknown is not zero. Missing timezone is not UTC. A repeated byte sequence is not necessarily a duplicate event. Corrected extraction creates a new revision; it does not overwrite the original.

See payload, time and provenance rules and the AI-assisted client guide.

Imports and reliable retries

Batch intake returns 202 only after recoverable input is persisted. Poll the batch for per-item results, and finalize the import after its last batch to seal intake. Accepted items survive later failures or cancellation.

Retry an uncertain POST with the same key and body. A changed body under the same key conflicts. Observation keys also prevent duplicate source occurrences across imports. Separate source occurrences with identical bytes remain separate records.

Errors and retry decisions explain validation failures, conflicts, preconditions and backpressure.

Bounded by design

Read GET /capabilities for the deployment's effective limits. The baseline envelope is 500 records per batch, 8 MiB request body, 64 KiB inline bytes per message, 64 KiB extensions and JSON depth 12. Lists default to 100 items and cap at 500.

Quotas and available features can vary by deployment. Larger evidence uses the authorized artifact workflow where enabled. An arbitrary file path or URL never grants server access to a file.