Technical notes

SchemaVela

SchemaVela

Independent notes on API schemas, data contracts, versioning, webhooks, and the tests that keep integrations compatible.

SchemaVela is a desk for people who design or consume HTTP APIs: backend and integration engineers, platform engineers, and technical product managers. Each note separates the schema of a message from the behavior around it, and says which document a factual claim comes from. This is not a product site. There is no client list, and there is no claim of a long archive before the first set of notes.

What a note separates
  1. Schema

    Fields, types, and which names have to be present in a message.

  2. Behavior

    Status codes, errors, retries, and effects a schema file does not state.

  3. Checks

    Validation and tests that compare a real message with the published contract.

Topic areas

The sections below are the subject index. A note lives in one section. Related questions are linked from the text, not repeated as a second copy of the same article.

  • Schemas

    What a schema states about a message, and which rules it leaves unstated.

  • API contracts

    Where a contract is more than the schema: behavior, compatibility, and client migration.

  • Versioning

    How a publisher signals a compatible addition and an incompatible break.

  • Webhooks

    Event envelopes, retries, signatures, and the receiver that must tolerate duplicates.

  • Integration design

    Boundaries, error bodies, and the mapping between two schemas.

  • Testing

    Schema checks, contract tests, and the cases that still need a joined run.

Start here if you are deciding what a contract should promise. The full set is listed with the current notes.

All current notes

Notes that share a publication date are listed alphabetically. This set was published together.

Checklists

These are working lists inside the notes. They are editorial review aids, not measurements of how often a change breaks a client.

  1. Check

    Field checklist

    Required names, unknown fields, enums, and null before a schema is published.

  2. Check

    Where to validate

    Producer, consumer, and the CI check, plus what a passing schema still misses.

  3. Check

    Which test to run

    When a contract test is the right evidence, and when a joined run is still required.

  4. Check

    Migration sequence

    Expand, migrate, and contract, and what to do if clients have not moved.

How these notes are written

Scope

The opening paragraph says what the note covers. It does not imply a result the page cannot show.

Table

A specification rule and an editorial reading stay in different columns. An empty cell is not a measurement.

Sources

A factual claim names its document. Illustrations are labeled as illustrations. The rules are on the editorial policy, and changes to a published fact go on corrections.