Skip to main content
Day-to-day work with the registry is four operations: register a schema, look at what’s registered, set the rules for how a subject may change, and check a candidate change before it ships. All examples assume SR_URL and API_KEY are set—see Connect.

​
Register a schema

Registering the same schema again is idempotent: you get the same ID back and no new version. Registering a different schema runs the subject’s compatibility check first. schemaType defaults to AVRO. Set it explicitly to JSON or PROTOBUF otherwise.
Registering a JSON schema on a subject that holds Avro versions is rejected with HTTP 409, in every compatibility mode including NONE. To change format, use a new subject.

​
Inspect what’s registered

List subjects:
List a subject’s versions, then read one:
Find which subjects a schema ID belongs to—useful when a consumer reports an ID it can’t resolve:
See REST API examples for the full set.

​
Set a compatibility mode

Read it back with GET /config/orders-value.
The global GET /config always returns {"compatibilityLevel":"NONE"} regardless of what’s in force. The real default is BACKWARD. There’s no PUT /config, so the global default can’t be changed—set the mode on each subject you care about.

​
Check a change before you ship it

Test a candidate schema without registering it. This belongs in CI, on every pull request that touches a schema file:
Fail the build on is_compatible: false and the incompatible change never reaches a cluster.

​
A workflow that holds up

Auto-registration means whichever producer connects first defines the subject. That’s fine for prototyping and poor for a shared platform. For subjects that matter:
  1. Turn off auto-registration in producers and set use.latest.version:
  2. Keep schema files in version control next to the code that uses them.
  3. Run the compatibility check in CI against the target subject.
  4. Register from the deploy pipeline, using a service account with schema-writer. Give application service accounts schema-reader only.
  5. Set the compatibility mode when you create the subject, rather than discovering the default later.

​
Replicate schemas to another cluster

Use Universal Linking to replicate schemas from an active cluster to one or more standby clusters. The standby registry runs in import mode: it accepts replicated schemas and rejects new registrations from producers. Schema Linking exporters aren’t available—see Confluent API compatibility.

​
Next steps

Delete schemas

Soft delete, hard delete, and what can’t be undone.

Schema ID validation

Enforce registered schemas at the broker.