Choose where OpenRTB validation runs.

The CLI, libraries, and gRPC service use the same Rust validator. Choose where to run it based on when you need findings and how your application handles failure.

Match validation to your workflow.

RTBlint deployment choices and their data flow
Where it runs	Payload and findings	Failure behavior
CI or local CLI	A fixture or NDJSON capture enters the CLI. Findings go to the console or a JSON report.	Validation errors return a failing exit code. Your build decides whether to block a change.
Application library	The request or response stays in your process. Rust and Node libraries return a validation report.	Your code decides whether to log, reject, or continue. Include validation time in your auction budget.
gRPC sidecar	Your application sends a document to your own validator service and receives a report.	Your caller sets the RPC deadline and decides what happens if the service is unavailable.
Captured bid stream	A separate consumer writes sampled traffic as NDJSON. The CLI emits per-payload findings or rule-frequency totals.	Validation happens outside the live auction path. Findings inform debugging and later changes.

These local modes do not upload payloads to rtblint.org. The browser tester and hosted MCP endpoint have separate payload-storage behavior.

Start with a fixture and a selected version.

cargo install rtblint
rtblint validate request.json --version 2.6-202606 --format json

Add an exchange profile when you need its documented requirements on top of the specification, for example --profile prebid-server. A valid report means there were no validation errors against that version and profile. It does not guarantee that a partner will bid, accept the request, or serve an ad.

Add the GitHub Action to CI, or use the Rust and Node library examples to validate in your application.

Use a sidecar when validation needs its own service.

# From a checkout of the rtblint repository:
cargo run -p rtblint-grpc

# Inspect the local service:
grpcurl -plaintext localhost:50061 list

Requests specify their payload kind, specification version, and optional exchange profile. The service provides reflection, health checks, and metrics. Measure the RPC and validation cost with your own payloads before adding it to an auction path.

Read the gRPC configuration and request examples.

Inspect captured traffic outside the auction path.

# One JSON payload per line:
rtblint validate --batch --summary bids.ndjson --version 2.6-202606

Keep the capture consumer separate from the auction consumer. Your infrastructure handles capture and sampling; RTBlint reads the NDJSON. Each payload gets a report, and the summary ranks rules by how often they fire. The homepage's Kafka viewer illustrates this pattern; it is not a packaged Kafka integration.

Keep the validation boundary explicit.

The core checks a payload against its selected specification and profile without fetching live resources. Supply-chain checks against sellers.json, ads.txt, or app-ads.txt require the CLI's opt-in --resolve --cache mode and a cache you provide. Business policy and auction outcomes remain decisions for your application.

Read the validation coverage and version-specific limitations.