The verification API lets another system confirm a credential without a browser: a partner’s HR platform checking a hire’s certification, a licensing board reconciling its register, your own portal showing staff credentials. It answers exactly what the public verification page shows, and nothing more, so giving a partner a key discloses nothing the page would not.
The Endpoint
GET https://your-site.example/wp-json/ppcert-enterprise/v1/verify/CREDENTIAL-ID
Send the key in either header:
Authorization: Bearer YOUR-KEY
X-PPCert-Key: YOUR-KEY
The Certificates > API Keys page carries the full endpoint documentation, with an example request and an example response for your site, so the partner’s developer can be sent a link rather than a write-up.
The Response
A JSON object with a status of valid, expired, revoked, or not_found. When the certificate exists, it also carries the certificate’s title, its issuer’s name and public profile link (when the certificate has an issuer), its issue date, and its expiry date (when it has one). Fields with no value are left out rather than sent empty. That is the verification page’s disclosure, field for field: no recipient email, no credential lists, no directory data.
Status Codes, and Why Not Found Is 200
- 200 with a status, including
not_found. A credential that does not exist is a normal answer, not an error, exactly as the public page treats it. This matters: an API that answered “no such credential” with an error code would let a script tell real IDs from wrong ones faster than a person could type them into the page. - 401: the key is missing, invalid, or revoked.
- 429: over the rate limit, with a
Retry-Afterheader saying how long to wait.
API Keys
Navigate to Certificates > API Keys (administrators only). Give the key a label that says who it is for, like “Acme HR”, and click Create key. The key is shown once; copy it then, because it cannot be displayed again. The list shows each key’s label, when it was created, when it was last used, and its status.
Give each partner its own key. Revoke stops requests with that key immediately and cannot be undone; if the partner needs access again, create a new key. Key creation and revocation, and a daily count of verifications per key, are recorded in the Audit Log.

Rate Limits and Access Without a Key
The Access section on the same page sets the limits. Each key gets its own allowance per minute (60 by default), so one partner’s traffic cannot crowd out another’s.
Allow verification without a key is off by default, which means every request needs a key. Turn it on and anyone can call the API; requests without a key then share one stricter limit per visitor (20 per minute by default). Consider it for a public integration where issuing keys is impractical, and leave it off otherwise. The public verification page is unaffected either way.
For a Web Page Instead of a System
If the partner wants verification on a page rather than in a system, they do not need to write against the API at all. See Embeddable Verification Widget.
