Skip to main content
A Certificate in the Volunteer API represents a training credential, badge, or achievement that volunteers can earn. Common uses include:
  • 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
Certificates have an expiration period — partner integrations can use this to detect when a volunteer’s credential is about to expire and trigger renewal outreach.

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:
⚠️ Spec gap (audit #14): The resource is referred to as “Certificate”, “Certification”, and “Certifications” in different places. The path is /certificates (the canonical URL); the schema is CertificateResource (the canonical type name).For partner integrations, use the path (/certificates) and the schema name (CertificateResource) as your reference points. The variations will be reconciled in a future spec revision.
For the rest of this page, the resource is referred to as Certificate — matching the path and schema name.

The Certificate resource

The CertificateResource schema documents these fields:
⚠️ Spec gap (audit #17): The CertificateResource schema is incorrectly typed as array in the spec — the same issue affecting FormResource and FormFieldResource. The actual response is a single Certificate object per item in the response’s data array. Code generated from the spec may need manual adjustment.
⚠️ Spec gap (audit #15): The slug field has the same enum-vs-example contradiction documented on FormResource. The enum lists form-field-like values (SHORTTEXT, LONGTEXT, etc.) and the example is a UUID. Treat the slug as a UUID string per the example; the misleading enum will be removed in a future spec revision.
⚠️ Spec gap (audit #16): The id field has minimum: 3, maximum: 45 constraints — string-length-style constraints applied to an integer. Treat IDs as unconstrained integers.

Expiration semantics

The expiration_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
Returns all Certificates in the customer’s organization, paginated:
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
For most customers, the list of available Certificates is short (typically a handful to a few dozen) — fitting comfortably in memory and changing infrequently. Cache the result aggressively.

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
A 1-hour TTL is reasonable — Certificates change rarely.

Map a Project’s required Certificates

Projects can require Certificates as a prerequisite for volunteering. The Project’s certificates array (on ProjectResource) lists which:
For partner integrations displaying Project requirements:
JavaScript
The result is a list of “what does a volunteer need to qualify for this Project?” — useful for signup pages, eligibility screens, or admin reports.

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.
The output is a list of “User X’s Certificate Y expires in N days” entries — feed this into the customer’s renewal outreach pipeline.

Sync Certificate list to a compliance system

For organizations with regulatory compliance requirements that need Certificate data in an external system:
JavaScript
Run daily or weekly. Certificates change infrequently; a less aggressive cadence is fine.

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
The 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.
Last modified on May 22, 2026