- Required safety training (e.g., food handler certification for food bank volunteers)
- Background check completion
- Specialized role qualifications (e.g., team leader training, CPR certification)
- Milestone achievements (e.g., 100-hour volunteer recognition)
- Compliance credentials for regulated programs
The one endpoint
That’s it. The API exposes only Certificate definitions (the “what certificates exist”) — not who has earned which Certificate, or when they earned it. Earned-certificate data isn’t exposed through a dedicated endpoint.
Information about which Users have earned which Certificates may be embedded in the User detail response (
GET /users/{id}) and the Project detail response (which lists required certificates). For workflows that need to know who has which Certificate, fetch User details and inspect the user’s earned certifications.The naming inconsistency
The Certificate resource has the most pronounced naming inconsistency of any resource in the Volunteer API:
For the rest of this page, the resource is referred to as Certificate — matching the path and schema name.
The Certificate resource
TheCertificateResource schema documents these fields:
Expiration semantics
Theexpiration_in_months field captures how long a Certificate remains valid after a User earns it:
For partner integrations, this is the dimension that drives renewal workflows — knowing the validity window for each Certificate type lets the integration compute “when does this user’s certification expire?” given their earn date.
The expiration is on the Certificate definition, not on the per-user earned record. So the same Certificate has the same validity window for everyone who earns it.
Listing certificates
cURL
The
/certificates endpoint doesn’t document explicit query filters in the spec. Pagination via ?page=N likely works the same as other list endpoints — follow links.next.JavaScript
Common workflows
Cache and look up Certificates by ID
The most common pattern — read the Certificate list once, cache it, then look up by ID when needed:JavaScript
Map a Project’s required Certificates
Projects can require Certificates as a prerequisite for volunteering. The Project’scertificates array (on ProjectResource) lists which:
JavaScript
Expiration renewal outreach
For workflows that watch for Certificates approaching expiration:JavaScript
The exact field name and shape of earned-certificate data on the User Detail response (
GET /users/{id}) isn’t documented in the OpenAPI spec — the example UserDetailResource only formally documents participations and profile_field_values. The pattern above assumes a field like earned_certificates with certificate_id and earned_at per entry, but confirm against the live API before relying on it.Sync Certificate list to a compliance system
For organizations with regulatory compliance requirements that need Certificate data in an external system:JavaScript
What can’t be done via the API
If a partner integration needs to programmatically award Certificates (e.g., after a User completes external training), coordinate with VOMO’s admin team for an alternative path.
See Understand Write Limitations.
A reference Certificates client
JavaScript
computeExpiration helper handles the most common operation — given an earned date and a Certificate, compute the expiration date.
Where to go next
Users
Users earn Certificates; the User detail response is where earned-certificate data lives.
Projects and Project Dates
Projects can require Certificates as prerequisites.
Forms and Form Completions
The other read-only structured-data resource family.
The Volunteer Data Model
The full data model context for Certificates.