Create a standalone public/private keypair, used to create Decentralized Identifiers (DIDs), using cheqd Studio.
In decentralized identity systems, all actors—whether Issuers, Holders, or Verifiers—require cryptographic keys to prove control over a Decentralized Identifier (DID) and to sign or verify interactions (e.g. credential issuance or presentation).
This tutorial guides you through generating a key pair that can be used to:
✅ Create a new DID (e.g. did:cheqd or did:key)
✅ Import into cheqd Studio for identity operations
✅ Use directly in SDKs or agent frameworks that support key-based identity
DIDs are built on public-private key cryptography. The public key is embedded in or referenced by the DID Document, while the private key remains securely held by the actor controlling the identity.
Without keys, you can’t:
Create a DID
Authenticate or prove control of an identity
Sign or verify credentials and presentations
Rotate or deactivate identifiers
cheqd Studio supports two cryptographic key types for identity operations:
✅ Choose
Ed25519for identity-specific use cases. Usesecp256k1if you need compatibility with blockchain-based tooling, wallets, or ecosystems that already rely on this curve.
Use the API below to create and generate your new identity key pair of either type Ed25519 or secp256k1.
If you've already generated a key pair using cheqd Studio and want to retrieve, reference or use it later, you can do so by referencing its Key ID (kid). This is useful for:
Recovering key material generated earlier (e.g., to construct a DID or sign a credential)
Working with shared or externally provisioned keys
Avoiding duplicate key creation when managing identities programmatically
Ed25519
The default and recommended key type for most DID and Verifiable Credential operations. Fast, secure, and widely supported across agent frameworks.
secp256k1
A widely adopted elliptic curve used in blockchain ecosystems (e.g. Bitcoin, Ethereum). Useful for cross-chain identity interoperability or aligning with Web3 wallets.
Resolve a did:cheqd Decentralized Identifier (DID) to fetch the associated DID Document, using cheqd Studio.
Resolving a DID means retrieving the associated DID Document, which contains the public keys, service endpoints, and metadata that describe and verify the identity. In decentralized identity systems, DID resolution is the foundation for:
Verifying the authenticity of a DID
Retrieving public keys for signature validation
Accessing service endpoints (e.g. credential issuance APIs)
Dereferencing to DID-Linked Resources (DLRs), such as status lists or trust registries.
A user is able to input a DID (string) as a request format and resolve the DID to fetch the associated DID Document, DID Resolution Metadata and DID Document metadata.
Deactivate a did:cheqd Decentralized Identifier (DID) using cheqd Studio.
Deactivating a DID marks it as no longer active or in use. This process updates the DID Document on the ledger to signal to verifiers, wallets, and other clients that the DID should no longer be trusted for interactions such as credential issuance or presentation.
Once a DID is deactivated:
✅ It cannot be updated again
❌ It cannot be reactivated
🛑 Applications resolving the DID will see its status marked as deactivated
You should deactivate a DID when:
The associated identity (e.g. organisation, credential issuer) is no longer operating
The cryptographic keys have been compromised or rotated to a new DID
You want to enforce a clean break with no further updates to the DID Document
To prevent unauthorized deactivations, a deactivate request must be signed by all of the Verification Method keys listed in the current DID Document.
This ensures that only the current controller(s) of the DID can authorize its deactivation.
🔐 If even one required key is missing or invalid, the request will be rejected.
Use the API below to submit a request to deactivate a did:cheqd DID.
Update a did:cheqd Decentralized Identifier (DID) using cheqd Studio.
Users are able to update DID Documents for various reasons, such as to include a new section (such as service) or to rotate the verificationMethod or authentication keys within the DID Document.
With the /did/update API, users are able to input either:
The specific section(s) of the DID Document to be updated; or
Create a Decentralized Identifier (DID) with the did:cheqd DID method using cheqd Studio.
In cheqd Studio, you can easily create and publish a did:cheqd DID to the cheqd testnet or mainnet, anchoring it on-ledger with associated public keys and metadata. This DID can then be used to:
Sign and issue verifiable credentials as an 'issuer'.
Establish a trusted identity on cheqd for entities like organisations, digital products or AI Agents.
Create Decentralized Identifiers (DIDs) and identity keys using cheqd's DID Method (did:cheqd).
The full updated DID Document body.
To update individual sections of the DID Document, users are able to pass only the section they would like to update. For example, users may often want to update the service section to add or change a serviceEndpoint:
The above request format will replace the service section of the existing DID Document with the new section. No extra information, such as the verificationMethod or authentication keys need to be passed with the request, because cheqd Studio custodies the keys on behalf of the user.
Users may regularly want to rotate the keys used to control the DID. Like with the service section above, users are able to pass the sections of the DID Document that include the rotated keys, usually contained within theverificationMethod and authentication sections.
The example above will rotate the keys that control the DID Document, updating the DID Document's verificationMethod and authentication sections accordingly.
Users may alternatively want to update the DID Document body in full, and pass the updated DID Document to the API. For example:
This method may be better for users wanting to update larger portions of the DID Document, or for having full visibility over the updated body.
Use the /did/update API below to pass your DID Document update as a request, using either the full body or a specific section.
This tutorial walks through the process of creating an Issuer DID using cheqd Studio's API or interface, including how to configure your keys, DID Document, and optional service endpoints.
🔐 Once registered, the DID becomes publicly resolvable and forms the cryptographic foundation of your identity as an issuer in decentralized ecosystems.
Make sure you have set up your account with cheqd Studio and have generated an API key to authenticate with our APIs, using our guides below:
Using the /did/create API, users have two options for creating a did:cheqd DID and associated DID Document on-ledger:
Filling out a simple form using the application/x-www-url-form-encoded or application/json option within an API client of your choice.
Compiling a full DID Document body yourself using the application/json option, using already created identity keys, within an API client of your choice.
This is the easiest way to create DIDs on cheqd and is recommended for users who are not overly familiar with compiling DID Documents.
Using the application/x-www-url-form-encoded option, users are able to choose between the following variables to compile your DID:
From this request, cheqd Studio will automatically create and publish a DID and associated DID Document to the ledger and return it as a response.
Alternatively, you can use the application/json option and pass only a few specific inputs, for example:
Or, if you have created a keypair already that you want to use, you can reference the created key ID, kid, in the request:
Using the application/json option, users are able to choose between the following variables to compile your DID:
Instead of generating a DID Document using simple parameters, you can create a fully formatted DID Document yourself. Before, submitting a manually created DID, you will need to have created a set of identity keys to input the key material into the DID document.
Use the /key/create API to generate a new keypair within the Credential Service key management store. Copy the publicKeyHex.
To simplify this process of formatting a DID Document using your own keys, we've created a Helper Tool in our DID Registrar here. Simply paste in your publicKeyHex and choose the variables to compile your DID Document template.
Within the /did/create JSON payload, paste the response of your DID Document template, with your own signing keys.
Request format:
Alternatively, you can use the application/json request format below.
You can use the kid created from Step 1 within the options section, and then compile the remainder of tour DID Document.
Hit execute on the API below to create your did:cheqd DID and associated DID Document.
After creating a DID or multiple DIDs, users can list all the created DIDs associated with their account. Using the /did/list API.
Below are a list of alternatives for creating cheqd DIDs.
There are many different ways to create DIDs on cheqd, with options for easy integration (e.g. cheqd Studio) and more bespoke integrations (e.g. Credo, ACA-Py and Veramo). Below are a list of SDK options for creating cheqd DIDs.
The easiest way to start creating DIDs is with our product cheqd Studio, allowing users to build and create did:cheqd DIDs using REST APIs.
cheqd DIDs are also supported in a range of SaaS offerings from cheqd partners, making it possible to use did:cheqd across different platforms:
DIDs created on cheqd use the did:cheqd DID Method. This is fully defined below, as well as the associated ledger-write fees:
Create a 'Holder' or 'Subject' Decentralized Identifier (DID), of method did:key using cheqd Studio.
In decentralized identity systems, Holders (also referred to as Subjects) are the recipients of Verifiable Credentials—typically representing individuals, organisations, objects or devices.
To enable credential interactions such as receiving, presenting, and proving control over an identity, each Holder needs a unique cryptographic key pair. This key pair is used to create a Decentralized Identifier (DID) that represents their identity.
After generating a key pair using the API below, you can use it to:
✅ Generate a did:key identifier, an off-ledger, self-contained DID that is ideal for lightweight identity use cases
did:key for Holders?The did:key method is a simple, deterministic DID method that embeds the Holder’s public key directly into the DID itself. It doesn’t require blockchain anchoring, making it:
⚡ Fast and lightweight – no on-ledger operations required
🔐 Privacy-preserving – good for ephemeral or throwaway identifiers
🧪 Useful for testing and interoperability – widely supported by wallets and agent frameworks
🧍 Ideal for Holder/Subject identities – where the main role is to receive and present credentials rather than issue them
Many ecosystems choose did:key for wallet-based identities, while keeping issuer DIDs on-ledger (e.g. did:cheqd) to ensure resolvability and public trust.
Take a deeper look into the did:key specification here:
Note that there are also perfectly valid use cases for using a did:cheqd DID for a 'Holder' or 'Subject' DID as well, where it is valuable to have the 'Holder' / 'Subject' identifiable on-chain.
For example, AI Agents, Organisations or products in a supply chain are good use cases for using did:cheqd.
This is because the 'Holder' / 'Subject' does not have Personally Identifiable Information (PII) associated with it.
To create a did:key DID, you can generate an identity key pair using the API below on cheqd Studio.
{
"did": "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881",
"service": [
{
"id": "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881#website",
"type": "LinkedDomains",
"serviceEndpoint": [
"https:example.com"
]
}
]
}{
"did": "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881",
"verificationMethod": [
{
"id":"did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881#key-2",
"type":"Ed25519VerificationKey2018",
"controller":"did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881",
"publicKeyBase58":"4sjwZ3VGWupJ26ytxjhU6LhjKiPrHV5reZbaNseyHtf8"
}
],
"authentication": [
"did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881#key-2"
]
}{
"didDocument": {
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/ed25519-2018/v1"
],
"id": "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881",
"controller": [
"did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881"
],
"verificationMethod": [
{
"id": "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881#key-1",
"type": "Ed25519VerificationKey2018",
"controller": "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881",
"publicKeyBase58": "4sjwZ3VGWupJ26ytxjhU6LhjKiPrHV5reZbaNseyHtf8"
}
],
"authentication": [
"did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881#key-1"
],
"service": [
{
"id": "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881#website",
"type": "LinkedDomains",
"serviceEndpoint": [
"https://example.com"
]
}
]
}
}{
"idFragment": "service-1",
"type": "LinkedDomains",
"serviceEndpoint": [
"https://example.com"
]
}{
"did": "did:cheqd:testnet:ca029356-69dc-4cb4-a4c6-13b959ffaad6",
"keys": [
{
"kid": "1a07cb379cd6f2d9acddf9a6d6af4e930d5696818a38020bde2b6ead5cd85039",
"kms": "postgres",
"type": "Ed25519",
"publicKeyHex": "1a07cb379cd6f2d9acddf9a6d6af4e930d5696818a38020bde2b6ead5cd85039",
"meta": {
"algorithms": [
"EdDSA",
"Ed25519"
]
},
"controller": "did:cheqd:testnet:ca029356-69dc-4cb4-a4c6-13b959ffaad6"
}
],
"services": [],
"provider": "did:cheqd:testnet",
"controllerKeyRefs": [
"1a07cb379cd6f2d9acddf9a6d6af4e930d5696818a38020bde2b6ead5cd85039"
],
"controllerKeys": [
{
"kid": "1a07cb379cd6f2d9acddf9a6d6af4e930d5696818a38020bde2b6ead5cd85039",
"kms": "postgres",
"type": "Ed25519",
"publicKeyHex": "1a07cb379cd6f2d9acddf9a6d6af4e930d5696818a38020bde2b6ead5cd85039",
"meta": {
"algorithms": [
"EdDSA",
"Ed25519"
]
},
"controller": "did:cheqd:testnet:ca029356-69dc-4cb4-a4c6-13b959ffaad6"
}
],
"controllerKeyId": "1a07cb379cd6f2d9acddf9a6d6af4e930d5696818a38020bde2b6ead5cd85039"
}{
"network": "testnet",
"identifierFormatType": "uuid",
"options": {
"verificationMethodType": "Ed25519VerificationKey2018"
}
}{
"network": "testnet",
"identifierFormatType": "uuid",
"options": {
"key": "8255ddadd75695e01f3d98fcec8ccc7861a030b317d4326b0e48a4d579ddc43a", // Pass kid if you have created a key separately
"verificationMethodType": "Ed25519VerificationKey2018"
}
}{
"didDocument": {
"id": "did:cheqd:testnet:0ff9df5d-653b-4f77-a66c-0035abc34d63",
"controller": [
"did:cheqd:testnet:0ff9df5d-653b-4f77-a66c-0035abc34d63"
],
"verificationMethod": [
{
"id": "did:cheqd:testnet:0ff9df5d-653b-4f77-a66c-0035abc34d63#key-1",
"type": "JsonWebKey2020",
"controller": "did:cheqd:testnet:0ff9df5d-653b-4f77-a66c-0035abc34d63",
"publicKeyJwk": {
"crv": "Ed25519",
"kty": "OKP",
"x": "BFSLOxwMJgpmWRtTUuo0JAvz6VXGp4WDDcN0dFfCQKo"
}
}
],
"authentication": [
"did:cheqd:testnet:0ff9df5d-653b-4f77-a66c-0035abc34d63#key-1"
]
}
}
"options": {
"key": "8255ddadd75695e01f3d98fcec8ccc7861a030b317d4326b0e48a4d579ddc43a",
"verificationMethodType": "Ed25519VerificationKey2018"
},
"didDocument": {
"@context": [
"https://www.w3.org/ns/did/v1"
],
"id": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0",
"controller": [
"did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0"
],
"authentication": [
"did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-1"
],
"service": [
{
"id": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#service-1",
"type": "LinkedDomains",
"serviceEndpoint": [
"https://example.com"
]
}
]
}
}cheqd Studio
Our API product enables users to use cheqd's functionality with minimal complexity and easily integrate APIs into existing apps.
Credo
Credo is an SDK which supports the European Architecture and Reference Framework (ARF) standards as well as AnonCreds with full cheqd support for DIDs.
ACA-Py
ACA-Py is a quickly expanding SDK, moving from the AnonCreds ecosystem towards wider support for EUDI.
Veramo
The Veramo SDK Plugin supports JSON, JSON-LD credentials as well as cheqd Credential Payments in an SDK.
Walt.id Community Stack
Walt.id Community Stack is an SDK that supports the European Architecture and Reference Framework (ARF) standards for identity, with full cheqd support.
DID Registrar
Simple setup for building cheqd DIDs into existing applications using REST APIs, building into the Universal Registrar.
cheqd Cosmos CLI
Cosmos CLI which directly communicates with the cheqd network. This should only be used for testing environments.
Create a DID
Create a Decentralized Identifier (DID) using the did:cheqd DID method using cheqd Studio.
Create a Subject DID
Create an off-ledger 'Subject' or 'Holder' DID using the did:keyDID method.
Resolve DID
Resolve a DID to retrieve the associated DID Document.
Godiddy
Godiddy from Danube Tech is a DID-specific SaaS offering focussed on enterprise registration and resolution of DIDs across multiple methods.
Paradym
Paradym by Animo Solutions fully supports EU Architecture & Reference Framework standards with cheqd under the hood.
Truvera (Dock)
Truvera is a full platform that supports credential issuance and management using cheqd as the primary DID Method.
Hovi Studio
Hovi provides an all-in-one platform for issuing and managing Verifiable Credentials with cheqd DIDs supported.
Cloud Platform (Walt.id)
Cloud Platform by Walt.id similarly fully supports EU Architecture & Reference Framework standards with cheqd under the hood.
Sudo Platform (Anonyome Labs)
API-first developer platform for cheqd DIDs and support for multiple Verifiable Credential formats.
DIDx
DIDx supports did:cheqd through an enterprise version of ACA-Py, supporting AnonCreds and JSON-LD.
cheqd DID Method
Click here to learn more about the cheqd DID method (did:cheqd).
DID Write Pricing
Click here to understand the price of DIDs and other resources on cheqd, compared to other identity networks.
Set Up Your Account
Set up your account with cheqd Studio and get your API key to start using the APIs.
Create API Keys
Create one or more API keys used to authenticate with the cheqd Studio APIs.
Credo
Credo is an SDK which supports the European Architecture and Reference Framework (ARF) standards as well as AnonCreds with full cheqd support for DIDs.
ACA-Py
ACA-Py plugin supports full cheqd support for DIDs as well as Verifiable Credentials.
Veramo
The Veramo SDK Plugin supports JSON, JSON-LD credentials as well as cheqd Credential Payments in an SDK.
DID Registrar
Simple setup for building cheqd DIDs into existing applications using REST APIs, building into the Universal Registrar.
Walt.id Community Stack
Walt.id Community Stack is an SDK that supports the European Architecture and Reference Framework (ARF) standards for identity, with full cheqd support.
cheqd Cosmos CLI
Cosmos CLI which directly communicates with the cheqd network. This should only be used for testing environments.
This endpoint fetches an identity key pair's details for a given key ID. Only the user account associated with the custodian-mode client can fetch the key pair.
Key ID of the identity key pair to fetch.
The request was successful.
A problem with the input fields has occurred. Additional state information plus metadata may be available in the response body.
Access token is missing or invalid
An internal error has occurred. Additional state information plus metadata may be available in the response body.
This endpoint returns the list of DIDs controlled by the account.
Filter DID by the network published.
Filter DID by the provider.
Include metadata in response.
Filter resource by created date
Page number.
Number of items to be listed in a single page.
The request was successful.
A problem with the input fields has occurred. Additional state information plus metadata may be available in the response body.
Access token is missing or invalid
An internal error has occurred. Additional state information plus metadata may be available in the response body.
{
"kid": "text",
"type": "Ed25519",
"publicKeyHex": "text"
}GET /key/read/{kid} HTTP/1.1
Host: studio-api.cheqd.net
x-api-key: YOUR_API_KEY
Accept: */*
{
"total": 1,
"dids": [
"text"
]
}GET /did/list HTTP/1.1
Host: studio-api.cheqd.net
x-api-key: YOUR_API_KEY
Accept: */*
This endpoint creates an identity key pair associated with the user's account for custodian-mode clients.
Key type of the identity key pair to create.
The request was successful.
A problem with the input fields has occurred. Additional state information plus metadata may be available in the response body.
Access token is missing or invalid
An internal error has occurred. Additional state information plus metadata may be available in the response body.
Resolve a DID Document by DID identifier. Also supports DID Resolution Queries as defined in the .
DID identifier to resolve.
did:cheqd:mainnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0Return only metadata of DID Document instead of actual DID Document.
Unique UUID version identifier of DID Document. Allows for fetching a specific version of the DID Document. See cheqd DID Method Specification for more details.
3ccde6ba-6ba5-56f2-9f4f-8825561a9860Returns the closest version of the DID Document at or before specified time. See DID Resolution handling for did:cheqd for more details.
1970-01-01T00:00:00ZThis directive transforms the Verification Method key format from the version in the DID Document to the specified format chosen below.
Query DID Document for a specific Service Endpoint by Service ID (e.g., service-1 in did:cheqd:mainnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#service-1). This will typically redirect to the Service Endpoint based on DID Resolution specification algorithm.
service-1Relative reference is a query fragment appended to the Service Endpoint URL. Must be used along with the service query property above. See DID Resolution specification algorithm for more details.
/path/to/fileThis endpoint deactivates a DID Document by taking the DID identifier as input. Must be called and signed by the DID owner.
DID identifier to deactivate.
List of key references (publicKeys) which will be used for signing the message. The should be in hexadecimal format and placed in the wallet of current user.
The request was successful.
A problem with the input fields has occurred. Additional state information plus metadata may be available in the response body.
Access token is missing or invalid
An internal error has occurred. Additional state information plus metadata may be available in the response body.
This endpoint updates a DID Document. As an input, it can take JUST the sections/parameters that need to be updated in the DID Document (in this scenario, it fetches the current DID Document and applies the updated section). Alternatively, it take the fully-assembled DID Document with updated sections as well as unchanged sections.
DID identifier to be updated.
did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0Authentication section of the DID Document.
List of key references (publicKeys) which will be used for signing the message. The should be in hexadecimal format and placed in the wallet of current user.
This endpoint creates a DID and associated DID Document. As input, it can take the DID Document parameters via a form, or the fully-assembled DID Document itself.
Network to create the DID on (testnet or mainnet)
Identity Provider to create the DID
Algorithm to use for generating the method-specific ID. The two styles supported are UUIDs and Indy-style Base58. See cheqd DID method documentation for more details.
Type of verification method to use for the DID. See DID Core specification for more details. Only the types listed below are supported.
The unique identifier in hexadecimal public key format used in the verification method to create the DID.
["https://www.w3.org/ns/did/v1"]This endpoint creates an identity key pair associated with the user's account for custodian-mode clients.
Key type of the identity key pair to create.
The request was successful.
A problem with the input fields has occurred. Additional state information plus metadata may be available in the response body.
Access token is missing or invalid
An internal error has occurred. Additional state information plus metadata may be available in the response body.
The request was successful.
A problem with the input fields has occurred. Additional state information plus metadata may be available in the response body.
Access token is missing or invalid
An internal error has occurred. Additional state information plus metadata may be available in the response body.
GET /did/search/{did} HTTP/1.1
Host: studio-api.cheqd.net
x-api-key: YOUR_API_KEY
Accept: */*
{
"@context": "https://w3id.org/did-resolution/v1",
"didDidResolutionMetadata": {
"contentType": "application/did+ld+json",
"retrieved": "2021-09-01T12:00:00Z",
"did": {
"didString": "did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47",
"method": "cheqd",
"methodSpecificId": "55dbc8bf-fba3-4117-855c-1e0dc1d3bb47"
}
},
"didDocument": {
"@context": [
"https://www.w3.org/ns/did/v1"
],
"id": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0",
"controller": [
"did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0"
],
"verificationMethod": [
{
"id": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-1",
"type": "Ed25519VerificationKey2018",
"controller": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0",
"publicKeyBase58": "z6MkkVbyHJLLjdjU5B62DaJ4mkdMdUkttf9UqySSkA9bVTeZ"
}
],
"authentication": [
"did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-1"
],
"service": [
{
"id": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#service-1",
"type": "LinkedDomains",
"serviceEndpoint": [
"https://example.com"
]
}
]
},
"didDocumentMetadata": {
"created": "2021-09-01T12:00:00Z",
"deactivated": false,
"updated": "2021-09-10T12:00:00Z",
"versionId": "3ccde6ba-6ba5-56f2-9f4f-8825561a9860",
"linkedResourceMetadata": [
{
"resourceURI": "did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47/resources/398cee0a-efac-4643-9f4c-74c48c72a14b",
"resourceCollectionId": "55dbc8bf-fba3-4117-855c-1e0dc1d3bb47",
"resourceId": "398cee0a-efac-4643-9f4c-74c48c72a14b",
"resourceName": "cheqd-issuer-logo",
"resourceType": "CredentialArtwork",
"mediaType": "image/png",
"resourceVersion": "1.0",
"checksum": "a95380f460e63ad939541a57aecbfd795fcd37c6d78ee86c885340e33a91b559",
"created": "2021-09-01T12:00:00Z",
"nextVersionId": "d4829ac7-4566-478c-a408-b44767eddadc",
"previousVersionId": "ad7a8442-3531-46eb-a024-53953ec6e4ff"
}
]
}
}POST /did/deactivate/{did} HTTP/1.1
Host: studio-api.cheqd.net
x-api-key: YOUR_API_KEY
Content-Type: application/x-www-form-urlencoded
Accept: */*
Content-Length: 26
"publicKeyHexs=['text']"{
"@context": "https://w3id.org/did-resolution/v1",
"didDidResolutionMetadata": {
"contentType": "application/did+ld+json",
"retrieved": "2021-09-01T12:00:00Z",
"did": {
"didString": "did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47",
"method": "cheqd",
"methodSpecificId": "55dbc8bf-fba3-4117-855c-1e0dc1d3bb47"
}
},
"didDocument": {
"@context": [
"https://www.w3.org/ns/did/v1"
],
"id": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0",
"controller": [
"did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0"
],
"verificationMethod": [
{
"id": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-1",
"type": "Ed25519VerificationKey2018",
"controller": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0",
"publicKeyBase58": "z6MkkVbyHJLLjdjU5B62DaJ4mkdMdUkttf9UqySSkA9bVTeZ"
}
],
"authentication": [
"did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-1"
],
"service": [
{
"id": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#service-1",
"type": "LinkedDomains",
"serviceEndpoint": [
"https://example.com"
]
}
]
},
"didDocumentMetadata": {
"created": "2021-09-01T12:00:00Z",
"deactivated": true,
"updated": "2021-09-10T12:00:00Z",
"versionId": "3ccde6ba-6ba5-56f2-9f4f-8825561a9860",
"linkedResourceMetadata": [
{
"resourceURI": "did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47/resources/398cee0a-efac-4643-9f4c-74c48c72a14b",
"resourceCollectionId": "55dbc8bf-fba3-4117-855c-1e0dc1d3bb47",
"resourceId": "398cee0a-efac-4643-9f4c-74c48c72a14b",
"resourceName": "cheqd-issuer-logo",
"resourceType": "CredentialArtwork",
"mediaType": "image/png",
"resourceVersion": "1.0",
"checksum": "a95380f460e63ad939541a57aecbfd795fcd37c6d78ee86c885340e33a91b559",
"created": "2021-09-01T12:00:00Z",
"nextVersionId": "d4829ac7-4566-478c-a408-b44767eddadc",
"previousVersionId": "ad7a8442-3531-46eb-a024-53953ec6e4ff"
}
]
}
}{
"kid": "text",
"type": "Ed25519",
"publicKeyHex": "text"
}POST /key/create HTTP/1.1
Host: studio-api.cheqd.net
x-api-key: YOUR_API_KEY
Accept: */*
POST /key/create HTTP/1.1
Host: studio-api.cheqd.net
x-api-key: YOUR_API_KEY
Accept: */*
{
"kid": "text",
"type": "Ed25519",
"publicKeyHex": "text"
}The request was successful.
A problem with the input fields has occurred. Additional state information plus metadata may be available in the response body.
Access token is missing or invalid
An internal error has occurred. Additional state information plus metadata may be available in the response body.
The request was successful.
A problem with the input fields has occurred. Additional state information plus metadata may be available in the response body.
Access token is missing or invalid
An internal error has occurred. Additional state information plus metadata may be available in the response body.
POST /did/update HTTP/1.1
Host: studio-api.cheqd.net
x-api-key: YOUR_API_KEY
Content-Type: application/x-www-form-urlencoded
Accept: */*
Content-Length: 1436
"did='did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0'&service=[{'id':'did:cheqd:mainnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#service-1','type':'LinkedDomains','serviceEndpoint':['https://example.com'],'priority':0,'recipientKeys':['did:cheqd:mainnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-1'],'routingKeys':['did:cheqd:mainnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-2'],'accept':['didcomm/aip2;env=rfc587']}]&verificationMethod=[{'controller':'did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0','id':'did:cheqd:testnet :7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-1','publicKeyBase58':'BTJiso1S4iSiReP6wGksSneGfiKHxz9SYcm2KknpqBJt','type':'Ed25519VerificationKey2018'}]&authentication=['text']&publicKeyHexs=['text']&didDocument={'@context':['https://www.w3.org/ns/did/v1'],'id':'did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0','controller':['did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0'],'verificationMethod':[{'id':'did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-1','type':'Ed25519VerificationKey2018','controller':'did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0','publicKeyBase58':'z6MkkVbyHJLLjdjU5B62DaJ4mkdMdUkttf9UqySSkA9bVTeZ'}],'authentication':['did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-1'],'service':[{'id':'did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#service-1','type':'LinkedDomains','serviceEndpoint':['https://example.com']}]}"POST /did/create HTTP/1.1
Host: studio-api.cheqd.net
x-api-key: YOUR_API_KEY
Content-Type: application/x-www-form-urlencoded
Accept: */*
Content-Length: 286
"network='testnet'&providerId='text'&identifierFormatType='uuid'&verificationMethodType='Ed25519VerificationKey2018'&service=[{'idFragment':'service-1','type':'LinkedDomains','serviceEndpoint':['https://example.com']}]&key='text'&@context=['https://www.w3.org/ns/did/v1']"{
"did": "text",
"controllerKeyId": "text",
"keys": [
{}
],
"services": [
{
"id": "did:cheqd:mainnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#service-1",
"type": "LinkedDomains",
"serviceEndpoint": [
"https://example.com"
],
"priority": 0,
"recipientKeys": [
"did:cheqd:mainnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-1"
],
"routingKeys": [
"did:cheqd:mainnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-2"
],
"accept": [
"didcomm/aip2;env=rfc587"
]
}
],
"controllerKeyRefs": [
"text"
],
"controllerKeys": [
"text"
]
}{
"did": "text",
"controllerKeyId": "text",
"keys": [
{}
],
"services": [
{
"id": "did:cheqd:mainnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#service-1",
"type": "LinkedDomains",
"serviceEndpoint": [
"https://example.com"
],
"priority": 0,
"recipientKeys": [
"did:cheqd:mainnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-1"
],
"routingKeys": [
"did:cheqd:mainnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-2"
],
"accept": [
"didcomm/aip2;env=rfc587"
]
}
]
}