Skip to main content
The StreamNative Kafka Schema Registry implements a subset of the Confluent Schema Registry API. Standard Confluent serializers, deserializers, and REST clients work against it unchanged for the operations listed below. This page is the reference for what’s supported, what isn’t, and—most importantly—the places where an endpoint exists but behaves differently than you’d expect coming from Confluent.

Supported endpoints

Schemas

Subjects

Compatibility

These are POST endpoints, not GET. POST /compatibility/subjects/{subject}/versions checks the candidate schema against every version, according to the subject’s configured mode.

Config and mode

Content types

The registry accepts application/vnd.schemaregistry.v1+json, application/vnd.schemaregistry+json, application/json, application/octet-stream, */*, or a missing Accept header. Any other value returns 412 Precondition Failed.

Unsupported endpoints

These return 404 Not Found: Unsupported query parameters—format, fetchMaxId, latestOnly, subjectPrefix, defaultToGlobal—are ignored rather than rejected.

Unsupported features

A schema registration that includes metadata or ruleSet succeeds. The request is accepted, those fields are discarded, and the schema is stored without them. No error is returned. If you’re migrating from Confluent and rely on schema rules, they will stop being enforced without any signal that anything changed.

Behavior differences

Endpoints that exist but don’t behave the way the Confluent documentation describes.

GET /config always reports NONE

The global GET /config returns {"compatibilityLevel":"NONE"} regardless of the compatibility level actually in force. The real default is BACKWARD. Use GET /config/{subject} to read the level that applies to a subject.

Subject names map to Pulsar coordinates

Subject names are parsed into tenant, namespace, and topic components:
A RecordNameStrategy subject like com.acme.MyRecord is parsed as tenant com, namespace acme, topic MyRecord—not as a single opaque name. If you use RecordNameStrategy or TopicRecordNameStrategy, verify that the resulting tenant and namespace exist and that your credentials cover them.
Subject names are limited to the characters [a-zA-Z0-9._-] and 249 characters. Anything else returns error code 42208.

Normalization is partial

?normalize=true performs real normalization for Avro and Protobuf schemas. For JSON Schema it’s a no-op—the schema is stored as submitted. On the /compatibility/* endpoints, normalize is parsed and then discarded for every format.

There is no undelete

A soft-deleted schema stays readable through ?deleted=true and ?deletedOnly=true, but there is no operation that restores it. Re-registering the same schema string after a soft delete creates a new version rather than reviving the old one. Hard delete (?permanent=true) requires a prior soft delete; calling it first returns 40405 for a subject or 40407 for a version. Hard-deleted data is unrecoverable.

Deletes are blocked by references

Deleting a schema that another schema references returns error code 42206. Delete the referencing schemas first, or use GET /subjects/{subject}/versions/{version}/referencedby to find them.

PUT /mode availability varies

Mode changes—READONLY, READONLY_OVERRIDE, and IMPORT—depend on how the registry is deployed for your cluster. On clusters that don’t support it, GET /mode always returns READWRITE and PUT /mode fails. IMPORT mode is normally set by Universal Linking replication on the standby cluster, not by client applications.

JSON $ref cannot reach external URLs

A JSON Schema $ref pointing at an external URL is rejected. Use schema references to compose schemas within the registry instead.

Broker-side validation uses different property names

Schema ID validation is configured with kop.kafka.* topic properties, not Confluent’s confluent.* properties. See Schema ID validation.

Extensions beyond Confluent

Limits

Error codes