@spec meter_error_report_event_json(map()) :: map()

The fully-fetched v2.core.event wrapping meter_error_report_json/1.

This is the shape LatticeStripe.Webhook.fetch_event/3 returns — not the delivered webhook body, which carries no data at all. related_object names the meter, and it is the only place the meter id appears: data never mentions which meter failed.

The top-level reason is null here, verbatim from the published example. Do not confuse it with data.reason — see LatticeStripe.Billing.MeterErrorReport.SampleError on the two near-identically named idempotency keys this event carries.

@spec meter_error_report_json(map()) :: map()

The data payload of a v1.billing.meter.error_report_triggered event.

Four fields, matching the published tree exactly: developer_message_summary, reason, validation_start and validation_end. There is no id, no object and no livemode — this is event data, not an addressable resource, and a fixture that invented any of them would teach the wrong shape.

validation_start / validation_end are RFC3339 strings, not Unix integers. That is the published encoding, verified against the live reference, and it is a legitimate asymmetry against every v1 object in this library (whose timestamps are Unix seconds).

The first sample error's request.identifier is the verbatim published value — note it is a bare UUID, not one of this library's own idk_ltc_-prefixed keys. Stripe echoes back whatever idempotency key the failing write actually used, which is exactly why an adopter who lets LatticeStripe.Client auto-generate one gets back a value that joins to nothing they own.

The second error type carries error_count 900 with an empty sample_errors list. That is the real high-volume shape — Stripe reports the count without sampling every failure — and the decoder must yield [] rather than nil for it.

@spec meter_id() :: String.t()

The meter id carried by meter_error_report_event_json/1's related object.

Exposed so a test can assert from_event/1 lifted this value rather than re-stating the literal and proving nothing.

@spec no_meter_found_meter_error_report_event_json(map()) :: map()

The sibling v1.billing.meter.no_meter_found event.

Its data tree is identical field-for-field to meter_error_report_event_json/1's — the two events share this payload byte-for-byte. The difference is that this one carries no related_object key at all, so there is no meter id to lift and from_event/1 must leave :meter nil rather than raising.