# snowplow tracker 400 bad request schema violation

## TL;DR
The collector rejected the event because it does not match its schema: wrong types, missing required fields, or a bad schema URI. Capture the failing payload, diff it against the schema in Iglu, fix the event construction, validate before sending, and confirm the collector returns 200.

```text
snowplow tracker 400 bad request schema violation
```

## Use this when

- Snowplow collector returns 400 for tracked events
- Events validate in development but fail in production
- The error started after a schema or tracker upgrade

## Not for this skill when

- Collector unreachable or DNS failures (network, not schema)
- 401 or 403 from the collector (authentication, not validation)
- Events arriving but with wrong data (tracking logic, not schema)

## Steps

### Step 1: Capture the failing payload

Intercept the exact JSON payload the tracker sends, from the network tab or collector logs. Expected: you hold the literal event that got the 400.

### Step 2: Diff against the Iglu schema

Open the schema version the event claims and compare field by field: types, required fields, formats. Expected: you find the violating field.

### Step 3: Fix the event construction

Correct the types, fill required fields, and use the exact schema URI and version. Expected: the constructed event matches the schema.

### Step 4: Validate before sending

Run the fixed payload through a schema validator locally. Expected: validation passes before any network call.

### Step 5: Confirm collector acceptance

Send the event and check for a 200 from the collector. Expected: events flow and appear in the pipeline.

## Tool compatibility

Snowplow JavaScript and server trackers; Iglu schema registry; Snowplow collector.

## Variant phrasings

### Variant 1

snowplow 400 bad request schema violation

### Variant 2

snowplow tracker event rejected iglu schema

### Variant 3

snowplow self-describing event 400 invalid schema

## Why it happens

Snowplow is schema-strict by design: every self-describing event must validate against its Iglu schema or the collector rejects it with a 400. That strictness is the product's value and its sharpest edge. The violations are usually mundane, a string where the schema wants a number, a null where a field is required, or a schema version bump (1-0-0 to 1-0-1) that the tracker was never told about. Because the tracker fires and forgets, the 400s accumulate silently in collector logs while the product team assumes data is flowing. Validating payloads in CI against the registry turns a production data outage into a build failure.

## Edge cases / pitfalls

- Schema version drift is the top cause; pin the schema version in the tracker config and bump deliberately.
- Null vs missing matters: some schemas reject explicit nulls but allow absent fields.
- Custom contexts each need their own valid schema; one bad context fails the whole event.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_QR_KFWqOXOEZ4SvP5dKLjA