Overview
The Certifier API is a REST-styled interface, providing programmatic access to much of the data in the system. It provides predictable URLs for accessing resources, and uses built-in HTTP features to receive commands and return responses. This makes it easy to communicate from a wide variety of environments: command-line utilities, gadgets, and even the browser URL bar itself.
Features
Certifier enables you to create professional certificates and badges with a fully customizable design interface. Whether you’re awarding participants for a course, event, or achievement, you can effortlessly:
- Design digital certificates or badges using a drag-and-drop editor
- Attach them to groups for batch issuance and management
- Host certificates on custom domains, giving your brand full visibility (e.g.,
certificates.yourcompany.com) - Customize the certificate view page — add your own colors, fonts, messages, and layout to match your brand or event style
From personalized layout to branded delivery, Certifier gives you full control over how your credentials are created, presented, and accessed.
Authentication
The Certifier API uses access tokens to authenticate requests. You can view and manage your access tokens in the Certifier Dashboard.
Security Notice: Your access tokens carry many privileges, so be sure to keep them secure! Do not share your secret access tokens in publicly accessible areas such as GitHub, client-side code, and so forth.
Authentication to the API is performed via HTTP Bearer Auth. Provide your access token in Authorization header with Bearer auth-scheme and Certifier-Version header:
Authorization: Bearer <TOKEN>
Certifier-Version: 2022-10-26
- All API requests must be made over HTTPS. Calls made over plain HTTP will fail
- API requests without authentication will also fail
- Access tokens can be created and managed from inside your account settings: Settings → Developers → Access Tokens
Versioning
The Certifier API is versioned. Our API versions are named for the date the version is released, for example, our latest version is 2022-10-26.
You set the version by including a Certifier-Version header.
API Endpoints
Create a Credential
POST https://api.certifier.io/v1/credentials
Use this endpoint to create a draft credential with the status = “draft”.
We can create custom attrinbutes for the certificate and pass the data via the api while creating credential.
As the next step, use the Issue a credential endpoint to issue a draft credential, making it active and accessible in the digital wallet.
curl --request POST \
--url https://api.certifier.io/v1/credentials \
--header 'Certifier-Version: 2022-10-26' \
--header 'accept: application/json' \
--header 'content-type: application/json' \
--data '{
"groupId": "string",
"recipient": {
"name": "string",
"email": "string"
},
"issueDate": "2025-08-07",
"expiryDate": "2025-08-07",
"customAttributes": {
"custom.mentor": "Jane Doe"
}
}'
Issue a Credential
POST https://api.certifier.io/v1/credentials/{id}/issue
Use this endpoint to issue a credential.
Use this endpoint to issue a draft credential and change the status from draft to issued. You can only issue credentials with thestatus = “draft”.
curl --request POST \
--url https://api.certifier.io/v1/credentials/id/issue \
--header 'Certifier-Version: 2022-10-26' \
--header 'accept: application/json'
Send a Credential
POST https://api.certifier.io/v1/credentials/{id}/send
Use this endpoint to send a credential.
Use this endpoint to send your recipient a published credential. You can only send credentials with thestatus = “issued”.
The only available deliveryMethod for now is email, which means that the Certifier will send an email to a recipient using the email template attached to the group a credential belongs to.
curl --request POST \
--url https://api.certifier.io/v1/credentials/id/send \
--header 'Certifier-Version: 2022-10-26' \
--header 'accept: application/json' \
--header 'content-type: application/json' \
--data '{
"deliveryMethod": "email"
}'
Credentials Search API
The Credentials Search API allows you to find and filter credentials using structured queries with logical operators, sorting, and pagination.
Search Request Structure
A search request payload consists of:
- filter – to define search conditions using AND, OR, and NOT logical operators
- sort – containing property and order, allowing control over result ordering
- Standard pagination using cursor and limit
Example Request
POST /v1/credentials/search
{
"filter": {
"AND": [
{
"status": {
"equals": "issued"
}
},
{
"recipient": {
"name": {
"contains": "John"
}
}
}
]
},
"sort": {
"property": "createdAt",
"order": "desc"
},
"cursor": "some_cursor_value",
"limit": 25
}
LocalStorage Tracking
This feature uses the browser’s LocalStorage to identify the actions made by the recipient of the credential.
How It Works
- When the user accesses the page with
?isRecipient=truequery parameter, the application saves that information in LocalStorage and removes the parameter from the URL - Actions taken afterwards in the same browser are recorded as the recipient’s, until the LocalStorage data is cleared
Important Considerations
- If you are distributing the credential links independently and wish to track events as originating from the recipient, be sure to include the
?isRecipient=trueparameter - Without this parameter, we won’t be able to mark this person as the recipient, and their actions will be marked under the guest actor category
Limitations
This approach may not capture every scenario:
- If a recipient opens a link with
?isRecipient=trueon one device, then shares the link without the parameter (or opens it on a different device without the stored flag), those subsequent views will be categorized as guest - If the user clears their LocalStorage or uses an incognito session, the system can no longer confirm that they are the recipient
Sample Certificate
Here’s an example of a certificate hosted on a custom domain: