Usage event validator

Paste the JSON your app sends for metered usage (one event or a batch of up to 100) and see what the Usage Lab API would answer: the exact HTTP status, error code and message for each problem, warnings for things that are valid but suspicious, and the normalized event that would be stored. It uses the same rules file as the playground, checked against the live API. Nothing is sent or stored.

Want to see the ledger row, the monthly rollup and the Stripe meter event body? Use the playground. Ready to send real events? See the API docs or drop in the LLM metering helper.

Embed this validator

Free to put in your docs or internal wiki. Copy the snippet:

Copy embed code · Preview the embed

FAQ

What does the usage event validator check?

Every rule the Usage Lab API applies to POST /api/v1/usage: meter, subscription or customer, value, unique_value, timestamp (30-day late window, 5-minute future skew), idempotency keys and batch limits. Errors show the exact HTTP status, error code and message the API returns.

Is my JSON sent anywhere?

No. Validation runs in your browser with the same rules file the playground uses. Nothing is sent or stored.

How do idempotency keys work in a batch?

Each event can carry its own idempotency_key. Otherwise the Idempotency-Key header is used, with the event index appended (key:0, key:1, ...). The same key twice in one request is rejected with duplicate_key_in_batch.

What is the largest batch?

100 events per request. A batch is all-or-nothing on validation errors: one bad event rejects the whole request.

Why a warning instead of an error?

Some events are valid but probably not what you meant: an unknown field (ignored; use properties), a value of 0, or a timestamp close to the 30-day late limit that a delayed retry would push past.