Manually Top Up Your Account with CHEQ.
Users may exhaust their usage limits in their cheqd Studio billing plan, but may want to continue using the Studio before their usage limits refresh. Therefore, users can manually top up their account with CHEQ tokens to use any APIs that involve a ledger-write, e.g:
Creating, Updating or Deactivating DIDs
Creating unencrypted or encrypted Status Lists
Creating Trust Registries
Creating other DID-Linked Resources
The following API can be used to fetch the new account information:
customer_id is used as an identifier for the particular customer using cheqd Studio. It is generated as a sub-field of the JWT token used in the authorization header.
cheqd_account is used to pay for identity transactions on either testnet or mainnet. A cheqd account is automatically generated when a new customer_id is generated.
If you exceed the usage limits in your cheqd Studio billing plan but want to continue using ledger-based functionality before your limits reset, you can manually top up your account using CHEQ tokens.
If you need to add CHEQ tokens to your cheqd Studio cheqd_account, there are a few steps you need to follow:
Once you have successfully created an account and have topped up your CHEQ tokens, you are ready to get started!
Get started with our tutorials for cheqd Studio functionality.
Credential history Updates and Credential Details
verify Credentials: both JWT and JSON-LD using file uploads and simple paste.
Add expiry status in Credential Details Page
error handling for jsonld credential verification
minor ui bugs and test provider
Add Download Credential & Supported Providers env
Add Credential issuance using cheqd Studio
Support for JWT and JSON-LD credentials
Begin integration of dock issuance & credential history
Create new page for issuance providers
Update schema type to array & Add member did validations
Validate Verification methods for Dock
Add email validation in credenitals
Adjusted responsiveness and min-max widths + more conservative resolution parallelisation limit
Augmented state handling + interactive management
Client-side favourable DID state management + table sorting
did dropdowns with consistent naming & schema handling in members
disable trust validation and tracking
fix expiry date not appearing correctly
encoded resourceName handling
error message on credential issue failure
Fix ecosystems state update
invalid did value passed in dropdown
Minor UI improvements
Pagination and enable Dock provider
resizing and assertionMethod toggle
significant improvement to session handling
Ui state management improvments
Integrate did metadata api
Display Resource Versions & UI improvements
Apply member filters in server
Create resource operation
Improved state management & fixes in list operations
Replace Buffer with Uint8arrays
Update Service section to support did name, type fields
Add organizations and agents as default options for identifiers
Url validations & Create DID form fixes
Support Trust ecosystems in UI, including accreditations for members in the ecosystem
Add authorization for specific schemas for members of ecosystems
Release versioning + v1.7.1 beta
Add create Resource underneath DIDs in UI
Optimize data rendering in create-resource
Add new Settings Tabs
User menu changes
nav bar update
Remove usdc prices
Add features for Dashboard and Api access in portal
Add create DID option in UI
Improve UI for managing API keys
cheqd_account address for using the Credential Service.Generate API Keys to securely authenticate with cheqd Studio APIs.
API keys are unique data strings used to authenticate a user and enable access to privileged operations on cheqd Studio APIs. All cheqd Studio APIs use API keys as the mechanism to authenticate client requests. Your API key should be kept confidential and secure at all times.
Authentication is required for all API requests; without it, the requests will fail.
All API requests must be made over HTTPS.
Because our API keys allow access to cheqd Studio APIs, you must keep them secure at all times.
Ensure your API key is always stored securely as soon as it is initially generated.
Make sure to copy your API key into a secure place, such as a Password Manager.
Never share it or record it in a publicly accessible medium (client-side code, public repositories, etc.).
Follow the tutorial here to get started with your cheqd Studio account.
Navigate to the "Developers" tab on cheqd Studio and select "Create an API Key". You are able to choose the expiry date of the API key, and it will automatically be set to expire 1 year from the current date.
Navigate to the "APIs" tab and copy/paste your API key into the API key box towards the top of your page. This will enable you to authenticate with the cheqd Studio APIs, allowing users to use cheqd Studio APIs within their existing Billing Plan and usage limits.
Get started with our tutorials for cheqd Studio functionality.
Get started with cheqd's API product offering for creating DIDs, trust registries and monetising credentials: cheqd Studio.
cheqd Studio is a set of APIs, guides and tutorials to help users establish an end-to-end trusted ecosystem for digital credentials.
Using REST APIs, customers can build cheqd's trust infrastructure into existing applications. All of cheqd’s existing open-source libraries remain available, and cheqd Studio does not necessitate developers to switch their SSI stack in their entirety, but allows them to build into their existing tooling, for example alongside APIs such as the Universal Resolver.
cheqd Studio directly leverages our Veramo SDK Plugin, making a wide array of features available from launch, including:
With cheqd Studio, there are multiple ways it can be deployed and hosted to support clients with different requirements.
This mode is the most simple for users, allowing cheqd to custody both Cosmos AND Identity keys in Veramo KMS. This means that manages both ledger-writes and signing identity transactions on behalf of the customer.
To ensure this is highly secure, we have deployed an instance of a Veramo Key Management Store (KMS) which uses a Postgress DB (TypeOrm) to store Cosmos AND identity keys in one encrypted table, so it cannot be read in plaintext. This design allows us to segment different customers' keys securely and efficiently.
We use similar techniques to Password Managers such as 1Password and Bitwarden to ensure that even if the database were to be compromised, the keys would remain encrypted and unusable.
Within Custodian mode, we also enable clients to toggle
Client-managed mode gives the cheqd Studio user the ability to utilise their own identity keys for signing identity transactions, while still allowing cheqd Studio to manage the CHEQ account keys for writing to the cheqd network. This mode is intended to be used for more production environments where the user signs each identity transaction independently, affording a greater level of security and control to the client.
Under the hood, cheqd Studio leverages our Veramo SDK Plugin for its identity functionality. Check out our guide on supported SDKs to understand how cheqd Studio fits together with our other Open Source packages.
If you would rather a deeper integration with lower-level packages, instead of REST APIs, take a look at our suite of cheqd supported SDKs below. Each offers a different set of protocols and underlying technical capabilities.
Follow these steps to create your account on cheqd Studio and begin using our APIs securely.
The user is required to Log In to our cheqd Studio portal and then access their API key to authenticate with our APIs. The API key guards the API from unauthorized access and is required for both testing production environments.
Head to our cheqd Studio and click Get Started.
cheqd Studio uses a to handle user authentication and login. You can create an account or sign in using:
Email and password
Google single sign-on
Discord login
Click Sign In or Create Account to continue.
Once signed in, create an API key from your account dashboard. This key is required to authenticate with cheqd Studio APIs and protects your environment from unauthorized access.
Get started with our tutorials for cheqd Studio functionality.
You will be able to get started for free on our free trial, but following the expiry of the free trial, users need to sign up for a paid billing plan. cheqd Studio billing uses as a payments processor and users will need to input their card information to initiate a billing plan.
cheqd Studio
Click here to sign up for a cheqd Studio plan to get started with creating API keys.
LOGTO_MANAGEMENT_API: URL of management API for LogTo (default is https://default.logto.app/api)
CORS_ALLOWED_ORIGINS: CORS allowed origins used in the app
User-facing APIs
LOGTO_APP_ID: Application ID for the cheqd Studio application in LogTo. This can be set up as type "Traditional Web"
LOGTO_APP_SECRET: Application secret associated with App ID above.
Machine-to-machine backend APIs
LOGTO_M2M_APP_ID: Application ID for machine-to-machine application in LogTo. This is used for elevated management APIs within LogTo.
LOGTO_M2M_APP_SECRET: Application secret
Default role update using LogTo webhooks: LogTo supports webhooks to fire of requests to an API when it detects certain actions/changes. If you want to automatically assign a role to users, a webhook is recommended to be setup for firing off whenever there's a new account created, or a new sign-in.
LOGTO_DEFAULT_ROLE_ID: LogTo Role ID for the default role to put new users into.
LOGTO_WEBHOOK_SECRET: Webhook secret to authenticate incoming webhook requests from LogTo.
Miscellaneous
DEFAULT_CUSTOMER_ID: Customer/user in LogTo to use for unauthenticated users
COOKIE_SECRET: Secret for cookie encryption.
Set Up Your Account
Begin your cheqd Studio set up, creating your account, creating an API key and authenticating with our APIs.
Create an API Key
Create your first API Key and authenticate with the cheqd Studio APIs to begin using the identity functionality.
Advanced Configuration Options
Run cheqd Studio yourself or use your own external database.
DIDs and Identity Keys
Create did:cheqd DIDs for credential issuers and for DID-Linked Resources.
Trust Registries
Create an end-to-end trusted ecosystem, using Trust Chains to build a full Trust Registry.
Payments
Create commercial models for verifiable credentials, such as verifier-pays-issuer.
Status Lists
Create status lists, including Bitstring Status List and Token Status List.
Verifiable Credentials
Issue any type of credential, including SD-JWT, VCDM and AnonCreds via our partners, including trust registries, status lists and payments.
DID-Linked Resources
Create custom resources for policies, presentation definitions, schemas and visual representations of credentials.
Credo
Credo is an SDK that is building directly towards supporting the EUDI standards, as well as support for AnonCreds.
ACA-Py
ACA-Py is a quickly expanding SDK, moving from the AnonCreds ecosystem towards wider support for EUDI.
Veramo
The Veramo SDK Plugin is an extension of the Veramo SDK, a JavaScript framework for Trusted Data, adding support for cheqd functionality.
Walt.id Community Stack
Walt.id Community Stack is an SDK that supports the European Architecture and Reference Framework (ARF) standards for identity, with cheqd DID support.
This endpoint returns the custodian-mode client details for authenticated users.
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 /account HTTP/1.1
Host: studio-api.cheqd.net
x-api-key: YOUR_API_KEY
Accept: */*
{
"customer": {
"customerId": "text",
"name": "text"
},
"paymentAccount": {
"mainnet": "text",
"testnet": "text"
}
}Advanced setup guide for running the cheqd Studio.
If you want to run the application without any external databases or dependent services, we provide a Docker Compose file to spin up a standalone service.
This standalone service uses an in-memory database with no persistence, and therefore is recommended only if you're managing key/secret storage separately.
The no-db.env file in the same folder contains all the environment variables necessary to configure the service. (See section Configuration above.)
Construct the postgres URL and configure the env variables mentioned above.
Spinning up a Docker container from the is as simple as the command below:
Configure the environment variables in the :
POSTGRES_USER: Username for Postgres database
POSTGRES_PASSWORD: Password for Postgres database
POSTGRES_MULTIPLE_DATABASES: Database names for multiple databases in the same cluster, e.g.: "app,logto". This sets up multiple databases in the same cluster, which can be used independently for External Veramo KMS or LogTo service.
Then, make the Postgres initialisation scripts executable:
Configure the environment variables in the with the settings described in section above.
Then, run the LogTo service to configure the LogTo application API resources, applications, sign-in experiences, roles etc using Docker Compose:
Configuring LogTo is outside the scope of this guide, and we recommend reading to familiarise yourself.
Configure the environment variables in the with the settings described in section above. Depending on whether you are using external Veramo KMS only, LogTo only, or both you will need to have previously provisioned these services as there are environment variables in this file that originate from Postgres/LogTo.
Then, start the service using Docker Compose:
When upgrading either the external Veramo KMS or LogTo, you might need to run migrations for the underlying databases.
You can run just the migration scripts using defined in the Compose file.
For example, to run cheqd Studio app migrations on an existing Postgres database (for external Veramo KMS):
Or to run LogTo migrations on an existing Postgres database:
To build your own image using Docker, use the provided.
docker compose -f docker/no-external-db/docker-compose-no-db.yml up --detachchmod +x docker/with-external-db/pg-init-scripts/create-multiple-postgresql-databases.shdocker compose -f docker/with-external-db/docker-compose-with-db.yml --profile logto up --detachdocker compose -f docker/with-external-db/docker-compose-with-db.yml up --detachdocker compose -f docker/with-external-db/docker-compose-with-db.yml --profile app-setup up --detachdocker compose -f docker/with-external-db/docker-compose-with-db.yml --profile logto-setup up --detachdocker build --file docker/Dockerfile --target runner . --tag credential-service:local