# Confluent Cloud Schema Registry REST API Usage Examples
The Schema Registry REST API allows you to register new schemas, list, look up, and delete schemas and subjects, and view these entities by version, by ID, and more.
For the full API reference, see [Schemas (V1)](https://docs.confluent.io/cloud/current/ccloud/schemas-v-1/) and [Subjects (V1)](https://docs.confluent.io/cloud/current/ccloud/subjects-v-1/).
## Setup and Suggestions
You’ll need to know the following to make API calls to the [Schemas (V1)](https://docs.confluent.io/cloud/current/ccloud/schemas-v-1/)
and [Subjects (V1)](https://docs.confluent.io/cloud/current/ccloud/subjects-v-1/) APIs per the usage examples provided here:
- API endpoint URL for the Confluent Cloud Schema Registry cluster in the environment you want to use. In the examples below,
this is typically referred to as the `` or `$SCHEMA_REGISTRY_ENDPOINT`. To find this on the Cloud Console,
navigate to an environment, select a cluster, click **Schema Registry** on the left menu, and click the **Endpoints** tab. Alternatively, log on to Confluent Cloud with the Confluent CLI,
make sure you have the appropriate environment selected (`confluent env list`, `confluent env use `),
and enter `confluent schema-registry cluster describe`. (A handy list of CLI commands is [here](https://docs.confluent.io/confluent-cli/current/command-reference/).)
- If you are using an API key, you need an API key and secret for Schema Registry in the environment you want to use.
(If needed, see [Create an API key for Confluent Cloud Schema Registry](../get-started/schema-registry.md#ccloud-sr-manage-api-keys-per-env).)
Schema subjects live at the level of an environment, in per-environment Schema Registry clusters,
so just choose the environment that contains the Kafka clusters you want to use.
- If you are using OAuth, you must provide your access token for authorization in the proper format, as described in [Use OAuth/OIDC to Authenticate to Confluent Cloud](../security/authenticate/workload-identities/identity-providers/oauth/overview.md#oauth-overview).
An OAuth example is provided below.
- To get properly formatted output for search calls that include question mark (`?`) or ampersand (`&`),
you must enclose the URL and search parameters in either single or double quotes so that the shell does not interpret them
This syntax is also shown in the examples.
- (Optional) The Confluent Cloud Schema Registry APIs provide support for [Schema contexts](/cloud/current/sr/schema-linking.html#schema-contexts).
These are an inherent part of schema linking, but can also be useful for grouping schemas in other scenarios.
- (Optional) You may want to store your API keys and Schema Registry URL in local shell environment variables to make testing easier.
For example, to store your API key and secret:
```bash
$MYCOOLKEYS=xyz:abc
```
You can check the contents of the variable with `echo $MYCOOLKEYS` then, use it
for authorization in subsequent commands: `curl --silent -u $MYCOOLKEYS -X POST -H "Content-Type: application/json" ...`.
- (Optional) For your API testing, you may want to use the `--silent` flag with the [curl](https://curl.haxx.se/) commands
and pipe the entire command through [jq .](https://stedolan.github.io/jq/) to get nicely formatted output.
If you don’t use `--silent` and `jq`, the content of the output will be the same, it just won’t be formatted as human-friendly readable.
(See the [Stream Catalog REST API Usage and Examples on Confluent Cloud](../stream-governance/stream-catalog-rest-apis.md#stream-catalog-rest-apis) documentation for examples of using these options.)
- (Optional) A [Confluent Cloud login](https://confluent.cloud/login) is handy for comparing API results with the Confluent Cloud Console ([https://confluent.cloud/](https://confluent.cloud/)).
## OAuth for Confluent Cloud Schema Registry REST API
Confluent Cloud Schema Registry REST API now supports OAuth, an open-standard authorization protocol for secure access.
To learn more about OAuth, see [Use OAuth/OIDC to Authenticate to Confluent Cloud](../security/authenticate/workload-identities/identity-providers/oauth/overview.md#oauth-overview) and [Configure Schema Registry Java clients](../security/authenticate/workload-identities/identity-providers/oauth/clients/java-clients.md#configure-sr-java-clients-for-oauth).
Here is an example of using Oauth to get a list of subjects from Confluent Cloud Schema Registry.
The generated reference documentation for this API is here.
```none
curl --request GET '/subjects/' \
--header 'Confluent-Identity-Pool-Id: ' \
--header 'target-sr-cluster: :` and follow the format shown above (specify identity pool ID, Schema Registry cluster, and OAuth bearer token).
## Schemas (V1) API Usage Examples
### Get schema by ID
[GET /schemas/ids/{schema-ID}](https://docs.confluent.io/cloud/current/ccloud/get-schema/)
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET \
--url '$SCHEMA_REGISTRY_ENDPOINT/schemas/ids/?subject=SOME_STRING_VALUE&format=SOME_STRING_VALUE&fetchMaxId='
```
#### NOTE
The `subject` query parameter acts as a search hint rather than a
filter. It identifies the first context to search when locating the schema
by ID, which helps in multi-context environments. It doesn’t restrict the
result to that subject.
For example, the following call gets the schema `my-flights`, which is associated with the schema ID 100015:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET --url $SCHEMA_REGISTRY_ENDPOINT/schemas/ids/100015?subject=flights&format=Avro&fetchMaxId=true | jq .
```
The resulting output is a wrapper object with a `schema` field containing the schema as a JSON string:
```none
{"schema":"{\"type\":\"record\",\"name\":\"sampleRecord\",\"namespace\":\"com.mycorp.mynamespace\",\"doc\":\"Sample schema to help you get started.\",\"fields\":[{\"name\":\"my_field1\",\"type\":\"int\",\"doc\":\"The int type is a 32-bit signed integer.\"},{\"name\":\"my_field2\",\"type\":\"double\",\"doc\":\"The double type is a double precision (64-bit) IEEE 754 floating-point number.\"},{\"name\":\"my_field3\",\"type\":\"string\",\"doc\":\"The string is a unicode character sequence.\"}]}"}
```
### Get schema string by ID
[GET /schemas/ids/{schema-ID}/schema](https://docs.confluent.io/cloud/current/ccloud/get-schema-only/)
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET \
--url '$SCHEMA_REGISTRY_ENDPOINT/schemas/ids//schema?subject=SOME_STRING_VALUE&format=SOME_STRING_VALUE'
```
#### NOTE
The `subject` query parameter acts as a search hint rather than a
filter. It identifies the first context to search when locating the schema
by ID, which helps in multi-context environments. It doesn’t restrict the
result to that subject.
For example, to get the schema string associated with the ID 100018:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET --url $SCHEMA_REGISTRY_ENDPOINT/schemas/ids/100018/schema | jq .
```
The output is the raw schema object directly:
```none
{"type":"record","name":"Employee","namespace":"Example","fields":[{"name":"Name","type":"string"},{"name":"Age","type":"int"},{"name":"Country","type":"string","default":""}]}
```
### List supported schema types
[GET /schemas/types](https://docs.confluent.io/cloud/current/ccloud/get-schema-types/)
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET --url $SCHEMA_REGISTRY_ENDPOINT/schemas/types | jq .
```
Example output:
```none
"JSON",
"PROTOBUF",
"AVRO"
```
### List schemas
[GET /schemas](https://docs.confluent.io/cloud/current/ccloud/get-schemas/)
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET \
--url '$SCHEMA_REGISTRY_ENDPOINT/schemas?subjectPrefix=&deleted=&latestOnly=&offset=&limit='
```
For example, to list all existing versions of schemas starting with subjectPrefix of `my-cool` and show the subject and schema for each:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET --url $SCHEMA_REGISTRY_ENDPOINT/schemas?subjectPrefix=my | jq .
```
Here is an example of partial output:
```none
{
"subject": "my-cool-subject",
"version": 2,
"id": 100018,
"schema": "{\"type\":\"record\",\"name\":\"Employee\",\"namespace\":\"Example\",\"fields\":[{\"name\":\"Name\",\"type\":\"string\"},{\"name\":\"Age\",\"type\":\"int\"},{\"name\":\"Country\",\"type\":\"string\",\"default\":\"\"}]}",
"ts": 1696522845123,
"deleted": false
},
{
"subject": "my-cooler-subject",
"version": 2,
"id": 100020,
"schema": "{\"type\":\"record\",\"name\":\"Employees\",\"namespace\":\"my.examples\",\"fields\":[{\"name\":\"Name\",\"type\":\"string\"},{\"name\":\"Age\",\"type\":\"int\"},{\"name\":\"region\",\"type\":\"string\",\"default\":\"\"}]}",
"ts": 1696522845124,
"deleted": false
},
{
"subject": "my-cooler-subject",
"version": 3,
"id": 100021,
"schema": "{\"type\":\"record\",\"name\":\"Employees\",\"namespace\":\"my.examples\",\"fields\":[{\"name\":\"Name\",\"type\":\"string\"},{\"name\":\"Age\",\"type\":\"int\"},{\"name\":\"region\",\"type\":\"string\",\"default\":\"\"},{\"name\":\"Team\",\"type\":\"string\",\"default\":\"\"}]}",
"ts": 1696522845125,
"deleted": false
},
...
```
### List subjects associated to a schema ID
[GET /schemas/ids/{schema-ID}/subjects](https://docs.confluent.io/cloud/current/ccloud/get-subjects/)
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET --url $SCHEMA_REGISTRY_ENDPOINT/schemas/ids//subjects
```
For example, to list the subject associated with ID 100018:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET --url $SCHEMA_REGISTRY_ENDPOINT/schemas/ids/100018/subjects
```
The output is:
```none
["my-cool-subject"]
```
### List subject-versions associated to schema ID
[GET /schemas/ids/{schema-ID}/versions](https://docs.confluent.io/cloud/current/ccloud/get-versions/)
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET \
--url '$SCHEMA_REGISTRY_ENDPOINT/schemas/ids//versions?subject=SOME_STRING_VALUE&deleted='
```
For example, the following call retrieves the subject-version associated with schema ID 100008:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET --url \
$SCHEMA_REGISTRY_ENDPOINT/schemas/ids/100008/versions?subject=stock | jq .
```
The output shows that version 2 of `stocks-value` is associated with the given ID:
```none
{
"subject": "stocks-value",
"version": 2
}
```
### Get schema by GUID
[GET /schemas/guids/{guid}](https://docs.confluent.io/cloud/current/ccloud/schemas-v-1/)
Retrieves the schema identified by the input GUID. GUIDs are used when schema IDs are included in Kafka headers for data governance.
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET \
--url '$SCHEMA_REGISTRY_ENDPOINT/schemas/guids/'
```
For example, to get the schema associated with a specific GUID:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET \
--url $SCHEMA_REGISTRY_ENDPOINT/schemas/guids/a1b2c3d4-e5f6-7890-abcd-ef1234567890 | jq .
```
The resulting output contains the schema information:
```none
{
"subject": "my-subject-value",
"version": 1,
"id": 100015,
"schema": "{\"type\":\"record\",\"name\":\"MyRecord\",\"fields\":[{\"name\":\"field1\",\"type\":\"string\"}]}"
}
```
### Get IDs by GUID
[GET /schemas/guids/{guid}/ids](https://docs.confluent.io/cloud/current/ccloud/schemas-v-1/)
Retrieves the schema IDs identified by the input GUID. This is useful when working with schema IDs in Kafka headers.
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET \
--url '$SCHEMA_REGISTRY_ENDPOINT/schemas/guids//ids'
```
For example, to get the IDs associated with a specific GUID:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET \
--url $SCHEMA_REGISTRY_ENDPOINT/schemas/guids/a1b2c3d4-e5f6-7890-abcd-ef1234567890/ids | jq .
```
The output returns the schema IDs:
```none
[100015]
```
## Subjects (V1) API Usage Examples
### List all subjects
[GET /subjects](https://docs.confluent.io/cloud/current/ccloud/list/)
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET --url $SCHEMA_REGISTRY_ENDPOINT/subjects | jq .
```
Here is example output, showing a list of subjects in the registry.
```none
"hamburgers",
"my-cool-subject",
"stocks_sell-value",
"Team",
"hamburger-test",
"accounts-value",
"stocks-value",
"stocks_under_100-value",
"employees-value",
"flights-value",
"my-widget-value",
"stocks_buy-value",
"my-flights-value",
"my-cooler-subject",
"my-new-widget-value",
"Hotdogs",
"my-value"
```
### List subject matching a given prefix
For example, list all versions of subjects starting with `my-cool`:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET --url $SCHEMA_REGISTRY_ENDPOINT/schemas?subjectPrefix=my | jq .
```
Here is an example of partial output:
```none
{
"subject": "my-cool-subject",
"version": 2,
"id": 100018,
"schema": "{\"type\":\"record\",\"name\":\"Employee\",\"namespace\":\"Example\",\"fields\":[{\"name\":\"Name\",\"type\":\"string\"},{\"name\":\"Age\",\"type\":\"int\"},{\"name\":\"Country\",\"type\":\"string\",\"default\":\"\"}]}"
},
{
"subject": "my-cooler-subject",
"version": 2,
"id": 100020,
"schema": "{\"type\":\"record\",\"name\":\"Employees\",\"namespace\":\"my.examples\",\"fields\":[{\"name\":\"Name\",\"type\":\"string\"},{\"name\":\"Age\",\"type\":\"int\"},{\"name\":\"region\",\"type\":\"string\",\"default\":\"\"}]}"
},
{
"subject": "my-cooler-subject",
"version": 3,
"id": 100021,
"schema": "{\"type\":\"record\",\"name\":\"Employees\",\"namespace\":\"my.examples\",\"fields\":[{\"name\":\"Name\",\"type\":\"string\"},{\"name\":\"Age\",\"type\":\"int\"},{\"name\":\"region\",\"type\":\"string\",\"default\":\"\"},{\"name\":\"Team\",\"type\":\"string\",\"default\":\"\"}]}"
},
...
```
### Get schema by version
[GET /subjects/{subject}/versions/{version}](https://docs.confluent.io/cloud/current/ccloud/get-schema-by-version/)
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET \
--url $SCHEMA_REGISTRY_ENDPOINT/subjects//versions/?deleted=
```
For example, to get version 2 of schema “my-cool-subject”:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET $SCHEMA_REGISTRY_ENDPOINT/subjects/my-cool-subject/versions/2
```
The result will be similar to the following, where the requested version of the schema is returned:
```none
{"subject":"my-cool-subject","version":2,"id":100018,"schema":"{\"type\":\"record\",\"name\":\"Employee\",\"namespace\":\"Example\",\"fields\":[{\"name\":\"Name\",\"type\":\"string\"},{\"name\":\"Age\",\"type\":\"int\"},{\"name\":\"Country\",\"type\":\"string\",\"default\":\"\"}]}"}
```
To retrieve a version of the schema that has been deleted (for example version 1 of my-cool-subject), use the following call:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET $SCHEMA_REGISTRY_ENDPOINT/subjects/my-cool-subject/versions/1?deleted=true
```
The requested version of the deleted schema is returned in the result:
```none
{"subject":"my-cool-subject","version":1,"id":100004,"schema":"{\"type\":\"record\",\"name\":\"Employee\",\"namespace\":\"Example\",\"fields\":[{\"name\":\"Name\",\"type\":\"string\"},{\"name\":\"Age\",\"type\":\"int\"}]}"}
```
### Get the latest version of a schema with its schema ID
[GET /subjects/{subject}/versions/{version}](https://docs.confluent.io/cloud/current/ccloud/get-schema-by-version/)
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET \
--url $SCHEMA_REGISTRY_ENDPOINT/subjects//versions/?deleted=
```
For example, to get the latest version of the schema for the “stocks” topic:
```bash
curl -u $SR_APIKEY:$SR_APISECRET --request GET --url $SCHEMA_REGISTRY_ENDPOINT/subjects/stocks-value/versions/latest
```
The output resembles the following:
```bash
{"subject":"stocks-value","version":2,"id":100008,"schema":"{\"type\":\"record\",\"name\":\"StockTrade\",\"namespace\":\"ksql\",\"doc\":\"Defines a hypothetical stock trade using some known test stock symbols.\",\"fields\":[{\"name\":\"side\",\"type\":\"string\",\"doc\":\"A simulated trade side (buy or sell or short)\"},{\"name\":\"quantity\",\"type\":\"int\",\"doc\":\"A simulated random quantity of the trade\"},{\"name\":\"symbol\",\"type\":\"string\",\"doc\":\"Simulated stock symbols\"},{\"name\":\"price\",\"type\":\"int\",\"doc\":\"A simulated random trade price in pennies\"},{\"name\":\"account\",\"type\":\"string\",\"doc\":\"Simulated accounts assigned to the trade\"},{\"name\":\"userid\",\"type\":\"string\",\"doc\":\"The simulated user who executed the trade\"}],\"connect.parameters\":{\"io.confluent.connect.avro.record.doc\":\"Defines a hypothetical stock trade using some known test stock symbols.\",\"io.confluent.connect.avro.field.doc.side\":\"A simulated trade side (buy or sell or short)\",\"io.confluent.connect.avro.field.doc.quantity\":\"A simulated random quantity of the trade\",\"io.confluent.connect.avro.field.doc.symbol\":\"Simulated stock symbols\",\"io.confluent.connect.avro.field.doc.price\":\"A simulated random trade price in pennies\",\"io.confluent.connect.avro.field.doc.account\":\"Simulated accounts assigned to the trade\",\"io.confluent.connect.avro.field.doc.userid\":\"The simulated user who executed the trade\"},\"connect.name\":\"ksql.StockTrade\"}"}
```
### List schemas referencing a schema
[GET /subjects/{subject}/versions/{version}/referencedby](https://docs.confluent.io/cloud/current/ccloud/get-referenced-by/)
```none
curl -u : --request GET \
--url /subjects//versions//referencedby
```
For example, the following call returns the schema IDs for schemas that reference version 1 of the `employees-value` schema:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET --url $SCHEMA_REGISTRY_ENDPOINT/subjects/employees-value/versions/1/referencedby
```
The output is `100027` which is the schema ID for the `widget-value` schema:
```none
[100027]
```
There are a few ways to get subjects associated with schema IDs; the most direct is to [List subjects associated to a schema ID](#api-list-subjects-associated-to-id)
using the following API call:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET --url $SCHEMA_REGISTRY_ENDPOINT/schemas/ids//subjects
```
(You could also [list all schemas](#api-list-all-schemas), but that would mean culling through them all to find the given ID.)
For example, to retrieve the subject associated with the given schema ID of `100027`:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET --url $SCHEMA_REGISTRY_ENDPOINT/schemas/ids/100027/subjects
```
The output is:
```none
["my-widget-value"]
```
which does reference `employees-value`.
If you walked through the full example with the example schemas and subject names or others of your own, you can verify this as follows:
1. Log on to the Confluent Cloud Console ([https://confluent.cloud/](https://confluent.cloud/)).
2. Navigate to **Environments** > **View & Manage Schemas** (on the right side panel), then click the schema that you configured to reference another
(in this example, `my-widget-value`).
3. Click **Evolve Schema** in the upper right.
Schemas referenced by the current schema will show under Schema References:
### Get schema string by version
[GET /subjects/{subject}/versions/{version}/schema](https://docs.confluent.io/cloud/current/ccloud/get-schema-only-1/)
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET\
--url $SCHEMA_REGISTRY_ENDPOINT/subjects//versions//schema?deleted='
```
For example, this call returns version 1 of the schema my-cool-subject, which had been deleted:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET \
--url $SCHEMA_REGISTRY_ENDPOINT/subjects/my-cool-subject/versions/1/schema?deleted=true | jq .
```
Example output:
```none
{"type":"record","name":"Employees","namespace":"my.examples","fields":[{"name":"Name","type":"string"},{"name":"Age","type":"int"}]}
```
### List versions under subject
[GET /subjects/{subject}/versions](https://docs.confluent.io/cloud/current/ccloud/list-versions/)
```none
curl -u $SR_APIKEY:$SR_APISECRET --request GET \
--url /subjects//versions?deleted=
```
For example, this call lists all versions for “my-cool-subject”:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET --url $SCHEMA_REGISTRY_ENDPOINT/subjects/my-cool-subject/versions
```
Example output showing all existing versions:
```none
[2,3,4]
```
This call lists all versions for “my-cool-subjects”, including deleted versions:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET --url $SCHEMA_REGISTRY_ENDPOINT/subjects/my-cool-subject/versions?deleted=true
```
Example output showing all versions, including those that were soft-deleted:
```none
[1,2,3,4]
```
### Register schema under a subject
[POST /subjects/{subject}/versions](https://docs.confluent.io/cloud/current/ccloud/register/)
To register a schema, specify a POST request with the following parameters:
- The `--data` flag provides the path to the file. You must include the `@` sign before the path with no spaces in between.
- Subject name under which to register the schema
To force a schema to become the latest version regardless of whether it already exists, you can pass `version: -1` in the request body. This is useful for infrastructure-as-code (IaC) scenarios where you need to ensure a specific schema version becomes the latest. For example, if you have schema versions v1, v2, and v3, and you want to make v1 the latest version again, you can re-register v1 with `version: -1`. When you use this parameter, Schema Registry adds a `confluent:version` key to the schema’s metadata section.
```none
curl -u : -X POST -H "Content-Type: application/json" \
--data @/Users/me/my.json /subjects//versions
```
Following is an example file you can pass into the POST request.
```none
{
"version": 0,
"id": 0,
"schemaType": "string",
"references": [
{
"name": "io.confluent.kafka.example.User",
"subject": "User",
"version": 1
}
],
"schema": "string"
}
```
### Lookup schema under subject
[POST /subjects/{subject}](https://docs.confluent.io/cloud/current/ccloud/look-up-schema-under-subject/)
To look up a schema, specify a POST request with the following parameters:
- The `--data` flag provides the path to the file. You must include the `@` sign before the path with no spaces in between.
- Subject name under which the schema is registered
```none
curl -u : -X POST -H "Content-Type: application/json" \
--data @/Users/me/my.json /subjects/
```
Following is an example file you can pass into the POST request.
```none
{
"version": 0,
"id": 0,
"schemaType": "string",
"references": [
{
"name": "io.confluent.kafka.example.User",
"subject": "User",
"version": 1
}
],
"schema": "string"
}
```
### Delete a subject
[DELETE /subjects/{subject}](https://docs.confluent.io/cloud/current/ccloud/delete-subject/)
This example deletes all versions of the subject “my-value”:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request DELETE --url $SCHEMA_REGISTRY_ENDPOINT/subjects/my-value | jq .
```
Example result showing versions 1 and 2 were deleted:
```none
1,
2
```
#### Delete Version 1 of the schema registered under a subject
[DELETE /subjects/{subject}/versions/{version}](https://docs.confluent.io/cloud/current/ccloud/delete-schema-version/)
This example deletes version 1 of a schema subject called “my-cool-subject”.
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request DELETE --url $SCHEMA_REGISTRY_ENDPOINT/subjects/my-cool-subject/versions/1 | jq .
```
Example result shows the version that was deleted:
```none
1
```
#### Recover a soft-deleted schema
You can recover a soft-deleted schema as described in [Recover a soft-deleted schema](schemas-delete-cc.md#cloud-schema-recover-soft-deleted).
1. The following example retrieves all deleted schema subjects:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET -X GET $SCHEMA_REGISTRY_ENDPOINT/subjects?deleted=true | jq .
```
2. This example re-registers a schema under the subject “my-cool-subject”:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET -X POST -H "Content-Type: application/vnd.schemaregistry.v1+json" \
--data '{"schema": "{\"type\":\"record\",\"name\":\"Employee\",\"namespace\":\"Example\",\"fields\":[{\"name\":\"Name\",\"type\":\"string\"},{\"name\":\"Age\",\"type\":\"int\"},{\"name\":\"Country\",\"type\":\"string\",\"default\":\"\"}]}"}' \
$SCHEMA_REGISTRY_ENDPOINT/subjects/my-cool-subject/versions | jq .
```
The result is a schema ID:
```none
"id": 100017
```
#### Delete the most recently registered schema subject under a given subject
The following example deletes the latest version registered under the subject `widget-value` (which has a total number of four versions as a starting point):
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request DELETE --url $SCHEMA_REGISTRY_ENDPOINT/subjects/widget-value/versions/latest | jq .
```
Example result shows the version that was deleted:
```none
4
```
#### Hard delete a schema
To [hard delete a schema](schemas-delete-cc.md#hard-delete-schema) and [free up schema storage space](schemas-delete-cc.md#sr-in-cloud-free-up-space) on Confluent Cloud,
first perform a soft delete of all versions of the schema, followed by a hard delete of all versions with the `?permanent=true` flag appended:
1. The following example executes a soft-delete of all versions registered under the subject `widget-value`:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request DELETE --url $SCHEMA_REGISTRY_ENDPOINT/subjects/widget-value | jq .
```
The example result shows that versions 1, 2, and 3 were deleted. (You already soft-deleted version 4 in the previous example.):
```none
1,
2,
3
```
At this point, the schema subject is “soft-deleted”. It doesn’t show on the Confluent Cloud Console or if you list subjects from the API,
but it is still taking up space in the registry. To hard-delete it, continue with the next step.
2. The following example performs a hard-delete of the subject `widget-value`:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request DELETE --url $SCHEMA_REGISTRY_ENDPOINT/subjects/widget-value?permanent=true | jq .
```
The output indicates that all versions have been permanently deleted:
```none
1,
2,
3,
4
```
## Schema Compatibility (V1) API Usage Examples
The following API calls enable you to get and set global and subject level compatibility. To learn about the compatibility types
available on Confluent Cloud Schema Registry, see [Schema Evolution and Compatibility](fundamentals/schema-evolution.md#schema-evolution-and-compatibility).
### Get the global compatibility level
[GET /config](https://docs.confluent.io/cloud/current/ccloud/get-top-level-config/)
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET --url $SCHEMA_REGISTRY_ENDPOINT/config/ | jq .
```
Example result:
```none
"compatibilityLevel": "BACKWARD"
```
### Update the global compatibility level
[PUT /config](https://docs.confluent.io/cloud/current/ccloud/update-top-level-config/)
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request PUT -H "Content-Type: application/vnd.schemaregistry.v1+json" \
--data '{"compatibility": ""}' --url $SCHEMA_REGISTRY_ENDPOINT/config/
```
For example, to update the global compatibility level to “BACKWARD_TRANSITIVE”:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request PUT -H "Content-Type: application/vnd.schemaregistry.v1+json" \
--data '{"compatibility": "BACKWARD_TRANSITIVE"}' --url $SCHEMA_REGISTRY_ENDPOINT/config/ | jq .
```
Example result:
```none
"compatibilityLevel": "BACKWARD_TRANSITIVE"
```
Now, if you re-run the call to [Get the global compatibility level](#schemas-get-global-compat-cc), you will get `"compatibilityLevel": "BACKWARD_TRANSITIVE"` in response.
### Get the compatibility level on a subject
[GET /config/{subject}](https://docs.confluent.io/cloud/current/ccloud/get-subject-level-config/)
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request GET --url $SCHEMA_REGISTRY_ENDPOINT/config/my-cool-subject | jq .
```
Example output:
```none
"error_code": 40408,
"message": "Subject 'my-cool-subject' does not have subject-level compatibility configured
```
### Update the subject compatibility level
[PUT /config/{subject}](https://docs.confluent.io/cloud/current/ccloud/update-subject-level-config/)
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request PUT -H "Content-Type: application/vnd.schemaregistry.v1+json" \
--data '{"compatibility": ""}' --url $SCHEMA_REGISTRY_ENDPOINT/config/
```
For example, to update the compatibility level for `my-cool-subject` to “FULL”:
```none
curl --silent -u $SR_APIKEY:$SR_APISECRET --request PUT -H "Content-Type: application/vnd.schemaregistry.v1+json" \
--data '{"compatibility": "FULL"}' --url $SCHEMA_REGISTRY_ENDPOINT/config/my-cool-subject | jq .
```
Example result:
```none
"compatibility": "FULL"
```
Now, if you re-run the call to [Get the compatibility level on a subject](#schemas-get-subject-compat-cc), you will get `"compatibility": "FULL"` in response.
## Suggested Reading
- [Schemas (V1)](https://docs.confluent.io/cloud/current/ccloud/schemas-v-1/)
- [Subjects (V1)](https://docs.confluent.io/cloud/current/ccloud/subjects-v-1/)