The explicit reference for what the Volunteer API cannot do — the complete write-surface inventory, the workarounds where they exist, and the escalation paths for capabilities that require admin team coordination.
The Volunteer API is heavily read-oriented. Of 24 endpoints, only 4 support writes (one upsert for Users, four endpoints for Groups, and two for Projects). Most operations a partner integration might want to do — recording participations, submitting Form responses, scheduling Project Dates, awarding Certificates — are not exposed in the API.This page is the canonical reference for those gaps. It enumerates what the API doesn’t support, organized by resource, with the workarounds where they exist and the escalation paths where they don’t. The audience is integration architects setting expectations during onboarding, support engineers triaging “can we do X?” questions, and engineers planning workflows.If you have a partner integration in design or production, treat this as the explicit “what to coordinate with the customer’s admin team on” list.
That’s it. Everything else — every other resource family and every other write operation — happens through the VOMO admin UI or through a separate admin-team coordination.
The most-requested missing capability. Participations are the central record of “this volunteer attended this Project Date” — and they’re entirely managed in the VOMO admin UI.
What partners often want
Status
Create a Participation (sign someone up programmatically)
Not exposed
Update a Participation’s check-in / check-out times
External event → Partner API → POST /participations (doesn't exist!)
The right flow is typically:
External event → Partner API → record locally → coordinate with admin team for batch import
Or, for workflows where pure VOMO authority isn’t required:
External event → Partner API → record locally → external system is authoritative; VOMO is sync target only via CSV
Set this expectation with customers during integration design. The API’s lack of Participation writes is the single biggest architectural constraint for most Volunteer integrations.
Read via GET /projects/{id} — Certificates listed on the Project
Display Certificates a user has earned
Read via GET /users/{id} (the exact field shape for earned certificates is not formally specified in the spec)
Track Certificate expiration for renewal workflows
Calculate from expiration_in_months on Certificate definition + earned date from User detail
Sync Certificate types to an external compliance system
Read via GET /certificates periodically
For workflows that need to award certificates programmatically (e.g., after a user completes external training), coordinate with the customer’s admin team — typically a CSV import or admin-UI workflow.
The Volunteer API has no webhook surface. Partner integrations that need to react to changes in VOMO data must poll. See Polling and Sync for the patterns.
Each query is a separate HTTP request. There’s no way to ask “give me these 10 users with these 5 fields each” in one request — you make 10 requests (or one large list query and then filter).
Coordinate with VOMO product team about future API support
Programmatic Project Date scheduling
Same
Programmatic Form submission
Same
Programmatic Certificate awarding
Same
These are common partner requests. If your integration’s design depends on one of them, raise it with VOMO product/integration leads early — the API surface evolves over time, and feedback from real integration needs influences what gets added.
For most partner integrations, VOMO is an information source — your integration reads from it and pushes that data into other systems. Treat external systems (CRMs, BI tools, accounting) as the destinations, with VOMO as the upstream.
2. Use Users + Groups as your primary write surface
The two write-capable resource families (Users via upsert, Groups via full CRUD) are where most “push into VOMO” workflows should focus. If your integration concept depends on writing to other resources, redesign or coordinate with admin team.
The most common customer disappointment is “I want my external system to automatically sign up volunteers for shifts” — which isn’t possible via API. Set this expectation explicitly during onboarding so the customer understands they (or their admin team) handle scheduling in VOMO, while your integration handles the data flow around it.
The lack of webhooks isn’t a deal-breaker; many production integrations operate fine on polling. Build polling architecture into your design from the start rather than retrofitting it. See Polling and Sync.
If you’re building a partner integration that surfaces VOMO data to end customers, document the same limitations in your own product docs. Customers will ask “why can’t I do X?” — and the answer is often “VOMO’s API doesn’t expose that,” not a limitation of your product.
