Publishing to the Credential Registry

What Can You Publish?

The Registry supports a broad range of resource types, not just credentials. Organizations can publish the full landscape of their offerings and connect those resources to one another, building a richer, more navigable picture of how credentials, programs, and competencies relate.

The resource types below represent the primary classes currently supported. Each has its own minimum data requirements and recommended properties, documented in the Credential Engine Minimum Data Policy.

For most organizations getting started, the natural entry point is publishing an Organization record first, followed by Credentials. Learning opportunities, assessments, and other resource types can be added incrementally over time.

Understanding CTIDs

Every resource published to the Credential Registry is assigned a Credential Transparency Identifier (CTID),  a globally unique identifier that serves as the permanent reference for that record. CTIDs are how the Registry tracks, updates, and connects resources to one another.

A CTID is formed by prefixing ce- to a version 4 UUID. For example:

Publishing Options at a Glance

The Registry is designed to meet organizations where they are. Whether your team is primarily composed of subject-matter experts or seasoned developers, there is a supported path for you. Options range from form-based manual entry to fully automated programmatic pipelines. The more technically oriented options are repeatable and scalable; once implemented, they can run automatically with minimal ongoing effort.

Publishing Workflows: First Party, Third Party, and Trusted Partners

The Registry supports several account and permission structures depending on who owns the data and who is doing the publishing. Understanding which workflow applies to your organization will shape how you set up your account.

A third-party publisher always uses its own API key — never the key belonging to the organization on whose behalf it is publishing. The Registry’s authentication layer validates whether a given API key is authorized to publish for a specific organization CTID before accepting any request.

Data Lifecycle and the Registry’s Permanence Policy

It is essential that information in the Registry is current and accurate. For each published credential or other resource, the issuing entity will be asked to estimate how often the information is likely to change. If the owner has not provided any updates on the credential within that timeframe, Credential Engine will automatically follow up with the owner to confirm that the existing information remains accurate.

Please review our Data Currency Policy for more information. 

Data in the Credential Registry is designed to be permanent. This is an intentional policy: even after a credential is no longer offered, a person who earned that credential should still be able to reference its details,  its competencies, requirements, and issuing organization. Deleting records undermines that principle.

Rather than deleting a resource that is no longer active, publishers should update its status to reflect its current lifecycle and republish it. The correct approach by resource type is shown below.

Resource Type	Status Property	Recommended Value
Credentials	Credential Status Type	Deprecated
Competency Frameworks	Publication Status Type	Deprecated
Organizations, Learning Opportunities, Assessments, Transfer Value Profiles, Collections	Life Cycle Status Type	Ceased

Deletion is reserved for genuinely erroneous records, such as accidental duplicates or test data published to production in error. The delete endpoint is available via the Registry Assistant API but should be used sparingly and only when the record has no legitimate purpose in the Registry’s history.

Your First Steps

Regardless of which publishing method you choose, every publisher follows the same initial setup path. Here is a concise checklist to move from zero to your first published record.

1. Create a Credential Engine account: Follow these instructions to create your user and organization accounts. If your organization already has an account, ask an account administrator at your institution to invite you by email. If you are unsure how to access your organization’s account, contact Credential Engine.
2. Review CTDL and the Minimum Data Policy: Familiarize yourself with the Credential Transparency Description Language and the required properties for each resource type you plan to publish. The Registry Assistant Handbook is a good starting point if you intend to publish via API. Understanding the data model before you begin will save significant rework later.
3. Determine CTID Management: Before publishing, generate CTIDs for each resource and store them in your source system. These identifiers are permanent and must be available every time you update or delete a record. We do not recommend publishing without a reliable CTID management strategy in place.

Publish your Organization record first: Your Organization record must exist in the Registry before any credentials, programs, or other resources it owns or offers can be published. 

Determine Your Path

1. For Bulk Upload publishing, we make available numerous guidance materials to support self-service publishing. 
2. For API Publishing, test in the Sandbox. Credential Engine maintains a sandbox environment specifically for testing and validation. Use it to confirm your data and workflow before publishing to production. The Credential Engine team can review your sandbox output, provide feedback, and troubleshoot issues before your data goes live. Once your organization has successfully completed sandbox testing, you will be approved for API publishing to the Registry.
3. For CTDL JSON-LD Ingest, publish data on your own website as CTDL-formatted linked open data following the guidance documented here. An automated process, managed either by the organization or by Credential Engine staff, periodically fetches the data and updates the supported referenced resources in the Registry.