# Managing Credential Types
Source: https://docs.chain.link/ace/guides/identity-manager/manage-credential-types
Last Updated: 2026-07-17

> For the complete documentation index, see [llms.txt](/llms.txt).

Credential types define the categories of attestations you can issue to [cross-chain identities (CCIDs)](/ace/concepts/cross-chain-identity). Each credential type represents a distinct kind of verification — for example, KYC completion, accredited investor status, or sanctions clearance. When you create a credential type, the `credential_type` string you provide is hashed to produce a `credential_type_hash` that policy contracts reference on-chain.

Credential types are scoped to a specific credential registry. Before creating credential types, make sure your [registries are set up](/ace/guides/identity-manager/manage-registries).

A credential type can optionally be linked to a **data schema**, which lets the credentials you issue against it carry structured data (for example, a jurisdiction code). See [Typed credentials with data schemas](#typed-credentials-with-data-schemas) below.

## What is a credential type?

A credential type is a string you define to represent a specific compliance check or verification. This string is hashed and registered on-chain, so it cannot be changed after creation. You can create any credential types that match your requirements — for example:

| Credential type string | Use case                               |
| ---------------------- | -------------------------------------- |
| `PROOF_OF_IDENTITY`    | Identity verification                  |
| `PROOF_OF_FUNDS`       | Source of funds or reserves check      |
| `AML_CHECK`            | Anti-money-laundering screening result |

The `credential_type` string is case-sensitive and must be unique within a registry.

## Define a credential type

Register a credential type with a `POST` request:

```bash
curl -X POST "https://ace.api.chain.link/v1/credential-types" \
  -H "Authorization: Apikey <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "registry_id": "<REGISTRY_ID>",
    "title": "KYC Verification",
    "credential_type": "KYC",
    "description": "Basic Know Your Customer identity verification"
  }'
```

The response includes the generated `credential_type_id` and the `credential_type_hash` derived from your `credential_type` string.

## Understand credential type hashes

When you create a credential type, ACE hashes the `credential_type` string to produce a deterministic `credential_type_hash`. This hash is what gets written on-chain and what policy contracts use when evaluating identity-based rules.

```text
credential_type string    →    credential_type_hash         →    on-chain reference
"KYC"                     →    0x7a8b...3f21                →    used by policy contracts
```

Because the hash is derived from the string, choosing your `credential_type` strings carefully matters — they cannot be changed after creation. Policy contracts such as the [Credential Registry Identity Validator](/ace/reference/policy-library/credential-registry-identity-validator-policy) reference credentials by their `credential_type_hash` when checking whether an identity holds a required attestation.

> **CAUTION**
>
> The `credential_type` string and its hash are immutable once the credential type is created. Choose your naming
> convention before issuing credentials against a type.

## Typed credentials with data schemas

By default, credentials are **attestation-only**: they record that an identity holds a credential of a given type, with no additional data. You can instead create a **typed** credential type by linking it to a **data schema**. Credentials issued against a typed credential type carry structured data (validated against the schema), which policies can then evaluate through a [Data Validator](/ace/guides/policy-manager/manage-data-validators).

A **data schema** is a reusable definition of the shape and format of a credential's data. ACE provides shared, ready-to-use schemas — the first is an [ISO 3166-1 alpha-2](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2) country code schema for jurisdiction use cases (an array of two-letter country codes such as `US`, `CA`, `GB`).

To make a credential type typed, pass a `data_schema_id` when you create it. The ISO 3166-1 alpha-2 country code data schema ID is:

```text
fb786cd7-6397-4ac6-790c-35746f343cad
```

```bash
curl -X POST "https://ace.api.chain.link/v1/credential-types" \
  -H "Authorization: Apikey <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "registry_id": "<REGISTRY_ID>",
    "title": "Jurisdiction",
    "credential_type": "common.country",
    "description": "Holder jurisdiction as ISO 3166-1 alpha-2 country codes",
    "data_schema_id": "fb786cd7-6397-4ac6-790c-35746f343cad"
  }'
```

Once a credential type is linked to a data schema, every credential you issue against it **must** include `credential_data` matching that schema — see [Issue a credential with data](/ace/guides/identity-manager/manage-credentials#issue-a-credential-with-data).

> **NOTE: Attestation-only stays the default**
>
> Linking a data schema is optional. Omit `data_schema_id` for a plain attestation credential type — the common case for
> yes/no checks like KYC or AML.

## View credential types

List credential types with a `GET` request. Use the `registry_id` query parameter to filter by registry:

```bash
curl "https://ace.api.chain.link/v1/credential-types?registry_id=<REGISTRY_ID>&page=1&page_size=25" \
  -H "Authorization: Apikey <API_KEY>"
```

To retrieve a single credential type by ID:

```bash
curl "https://ace.api.chain.link/v1/credential-types/<CREDENTIAL_TYPE_ID>" \
  -H "Authorization: Apikey <API_KEY>"
```

## Update a credential type

You can update a credential type's **title** and **description**. The `credential_type` string and `credential_type_hash` cannot be changed.

Update a credential type with a `PUT` request:

```bash
curl -X PUT "https://ace.api.chain.link/v1/credential-types/<CREDENTIAL_TYPE_ID>" \
  -H "Authorization: Apikey <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "KYC Verification (Enhanced)",
    "description": "Enhanced KYC verification including document and liveness checks"
  }'
```

You can also make partial updates with a `PATCH` request:

```bash
curl -X PATCH "https://ace.api.chain.link/v1/credential-types/<CREDENTIAL_TYPE_ID>" \
  -H "Authorization: Apikey <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "description": "Updated description for KYC verification"
  }'
```

## Archive a credential type

Archiving a credential type prevents new credentials of that type from being issued. Existing credentials remain valid until they are individually archived or expire.

> **CAUTION**
>
> All credentials issued under a credential type must be archived before the credential type itself can be archived. See
> [Managing Credentials](/ace/guides/identity-manager/manage-credentials) for how to archive individual credentials.

Archive a credential type with a `PATCH` request:

```bash
curl -X PATCH "https://ace.api.chain.link/v1/credential-types/<CREDENTIAL_TYPE_ID>" \
  -H "Authorization: Apikey <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "status": "archived"
  }'
```

If active credentials still reference the type, the request returns an error. Archive all associated credentials first, then retry.

## Related resources

- [Cross-Chain Identity](/ace/concepts/cross-chain-identity) — conceptual overview of CCIDs, registries, and credential types
- [Managing Credentials](/ace/guides/identity-manager/manage-credentials) — issue, revoke, and manage credentials linked to CCIDs
- [Managing Registries](/ace/guides/identity-manager/manage-registries) — view and manage identity and credential registry deployments
- [Credential Registry Identity Validator Policy](/ace/reference/policy-library/credential-registry-identity-validator-policy) — the policy contract that checks credentials on-chain