Schema Registry
One connection decodes what you read; its twin encodes what you produce.
Both Schema tabs can connect a Confluent-compatible Schema Registry over HTTP. The connection is live and per tab: it is not saved, and it is gone when the tab disconnects or the app closes. How it encrypts and proves who is asking is its own section: Registry Security, below.
Two connections
The consumer and the producer each hold their own registry, configured from their own Schema tab, and the two never touch: connecting the producer's does not switch the consumer's decoding on, and disconnecting one leaves the other standing.
The consumer's
Resolves framed rows by the schema id each message carries, as the fallback after the schemas supplied on the tab.
The producer's
Encodes the value against the schema the registry holds for the topic's subject, validating it before the send.
Both outlive what happens around them: clearing messages drops neither connection, and neither does choosing another topic; the producer's subject follows the topic.
Connecting
Add registry opens the connection form: the registryURL, the credentials, and TLS. Connectverifies the registry answers before anything is configured: a failure changes nothing, and the form stays open with the reason.
The reason names the actual fault. A url that cannot be parsed is reported as an invalid url, not as unreachable, since nothing was reached for. A registry that could not be reached carries the underlying cause (a refused connection, an unknown host, a TLS failure) instead of a bare timeout. And a registry that answered but refused carries the server's own words: seeRegistry Security.
Reading with it
The order is fixed (see Consumer): a framed row is tried against the supplied schemas first, and the registry resolves what they do not, by the id in each message. There is no subject or catalog to pick; the message names its schema.
Old rows are not left behind. A framed row with no schema reads schema id N, its body not decoded. Connect a registry and that row decodes too, not just what arrives next: watching first and connecting later works. The same holds between the two sources: remove a supplied schema and its rows re-decode through the registry.
Fetched once, kept. A schema id is immutable within a registry, so each id is fetched once and cached. A failed resolve backs off, and the row notes the reason: an id the registry does not hold, or refused credentials, are held for minutes (they will not fix themselves mid-watch), while an unreachable registry is retried on a window that doubles from seconds up to a minute, so a struggling registry is not hammered by a busy topic. Reconnecting clears the cache: the same id under a different registry is a different schema.
Producing against it
The connection is the switch: while the producer's registry is connected and a topic is chosen, Produce encodes the JSON value against the registry's schema for the topic's value subject,<topic>-value, and frames it with that schema's id. There is no separate toggle. The producer never registers or alters a schema; it encodes against what the registry already holds, and the registered format it encodes to is Avro. A subject registered in another format fails the check instead: the schema could not be read as Avro, and the check says so.
Only the value is encoded. The key goes as you typed it, without a schema, and the Key tab says so while a registry is connected; on a topic whose keys are registered too, that is the thing to know. Headers travel as they are.
What was checked is what is sent. The produce encodes against the exact schema id the check validated, so a new version registered between your check and your send does not change what your bytes claim to be.