# event-schema-violated

An event does **not match the schema** of its event type.

- **Routes:** `write-events`, `register-event-schema`, `restore-backup`, and `import-events`
- **Description:** `/events/<index>: event does not match the schema of its type: <reason>` when writing events, with the place of the event in its list, counting from 0, and the reason, such as `missing properties: 'isbn'`, and `event does not match the schema of its type: <reason>` when registering a schema, restoring a backup, or importing events
- **Details:** When writing events, **`event`**, the place of the event in its list, counting from 0. When registering a schema, restoring a backup, or importing events, **`eventId`**, the ID of the event. If several do not match, a registration names the earliest, and a restore or an import the first it finds.

## Why It Happens

Once an event type has a **[schema](/learn/tutorials/first-steps-with-eventsourcingdb/registering-event-schemas)**, **every event of the type has to match it**. The reason names what is wrong, such as a required property that is missing, a value of another type, as in `/isbn: expected string, but got number`, or a property that the schema does not allow, as in `additionalProperties 'pages' not allowed`. It names **at most the first ten violations**, in the order of where they lie, separated by semicolons, and ends with `; and more` where there are more, without counting them. A violation within an alternative of `anyOf` or `oneOf` counts towards the ten as well, and where the ten end within an alternative, the reason ends there. A write with such an event is refused as a whole, and **none of its events is written**.

Registering a schema checks **every event of the type that is stored already**, and every one that is written while the check runs, and refuses the schema if one of them does not match. Restoring a backup checks every event of the backup against the schema that the backup registers for its type. It checks each event as it reads it, but the events of an earlier part against a schema that a later part registers only after the last part, so **a later event can be named before an earlier one**. Importing events checks every event against the schema that was registered for its type before the import, as it reads the event.

## How to Fix It

When writing events, send data that matches the schema. When registering a schema, write one that every stored event of the type matches, since stored events never change, and for data of another shape, use a **[new event type](/docs/eventsourcingdb/event-types#versioning)**. Sending the same request again fails the same way, since a schema can be neither replaced nor removed.

## Example

For a write whose second event, of the type `io.eventsourcingdb.library.book-acquired`, leaves out the `isbn` that the schema of its type requires, EventSourcingDB answers with this error, as a line of the stream, and then ends the stream with its `end` item:

```json
{
  "type": "error",
  "data": {
    "code": "https://docs.eventsourcingdb.io/errors/event-schema-violated",
    "description": "/events/1: event does not match the schema of its type: missing properties: 'isbn'",
    "details": {
      "event": 1
    }
  }
}
```