Choose between recipient imports, the issuer API and verification
Use the right integration for incoming registrations, your own certificate records or independent checks.
Three workflows with different purposes
- Connected imports bring recipient data from a supported sheet or registration webhook into a set.
- The issuer API reads your organization's own certificates by serial for your server-side systems.
- The verification API checks a certificate's signed record and status for a verifier.
The issuer API is read-only. It does not issue, edit or withdraw certificates, and an issuer lookup is not counted as an independent verification. Do not design an automated issuing integration around a lookup endpoint.
Request and protect an issuer key
- Have an owner or admin contact support with the organization and the intended use.
- Store the issued key on your server in a secret store or environment variable.
- Use the Authorization bearer header described in the issuer API reference.
- Keep the key out of browser code, mobile app bundles, URLs, screenshots and public repositories.
- If the key is exposed or no longer needed, ask for revocation. A lost key is replaced rather than revealed again.
Read lookup results correctly
A request can look up up to 100 serials. Inspect each item's found status and current certificate, including replacement history. A missing result can mean the serial is outside the organization's accessible records. A returned PDF URL does not bypass the certificate-download authorization rules.
Handle failures
Treat authentication failures as a key or access problem, rate limits as a reason to back off, and temporary server errors as incomplete work. Do not convert an API error into a claim that a certificate is fake. Follow the current endpoint reference for request shapes, limits and error behavior.
For incoming registrations, read Connected imports. For checking other issuers' awards, use the verification API reference.
Still stuck? A person will help.
Contact us