The four write endpoints
For reference, the only write surface in the API:
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.
Participation: not exposed
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 can do instead
Why this matters for architecture
Many partner integrations imagine a flow like:Project Date: not independently managed
Project Dates exist only as part of a Project. You cannot:What partners can do
See Create or Update a Project: Adjust a Project’s schedule for the schedule-modification pattern.
The “can’t have zero dates” constraint
Becausedates is required on PUT /projects/{id}, you can’t remove all Project Dates from a Project via the API. Implications:
- “Cancel all future shifts” requires either keeping a placeholder date or deleting the Project (which requires admin UI)
- Programmatic cleanup of expired schedules has friction
Form submission: not exposed
Form Completions are read-only via the API. Partners cannot:What partners can do
Certificates: read-only
Certificates have a singleGET /certificates endpoint and nothing else:
What partners can do
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.
Organizations: read-only
Organizations are entirely admin-UI-managed:What partners can do
For workflows that need to provision new child organizations (e.g., expanding a customer’s family programmatically), coordinate with VOMO support.
Campaigns: read-only
Campaigns are entirely admin-UI-managed:What partners can do
For partner integrations that want to create programmatic per-customer Campaigns, coordinate with VOMO support.
Users: limited write surface
Users have one write endpoint (POST /users) — an upsert by email. Beyond that:
What partners can do
See Create or Update a User for the upsert details and the email-change problem.
Groups: full CRUD (the exception)
Groups are the one resource family with full write support:
If your integration needs programmatic organization of users into stable collections, Groups are where you do it. See Manage Groups and Members.
Other notable missing capabilities
No webhooks
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.No bulk operations
Every write is a single-resource operation. There’s no:- Bulk User upsert (one body with many users)
- Bulk Group create
- Bulk member-add across multiple Groups
- Bulk operation for any other resource
No PATCH (partial update)
All updates are full-record replacement via PUT. The implications:
For high-concurrency workflows, consider locking or coordination at the partner integration level.
No conditional requests
The API doesn’t supportIf-Modified-Since or ETag-based conditional reads. Every GET re-fetches the full record.
No field-level filtering
The API doesn’t support?fields=name,email style sparse-fieldset queries. You always get the full resource shape.
No GraphQL or batch query endpoint
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).Escalation paths
When a partner integration needs something the API doesn’t support, the path forward depends on the type of need:For one-time data operations
For ongoing programmatic needs
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 VOMO product / API issues
What this means for integration design
A few principles to bake into integration architecture given these limitations:1. Treat VOMO as a read source for most data
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.3. Build expectations into customer onboarding
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.4. Polling is fine — design for 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.5. Cache aggressively
The lack of conditional requests, the small page size, and the read-heavy nature of typical workflows all argue for aggressive caching. Cache:- Form field definitions (change rarely)
- Certificate definitions (change rarely)
- Organization data (changes rarely)
- Project schedules (between updates)
- User detail (between known changes)
6. Document gaps in your own partner docs
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.A self-check before promising features
Before promising a customer that your integration can do something, walk through this:- Can the operation be done via one of the four write endpoints?
- If not, can the data be captured externally and synced separately?
- If a sync is needed, does the customer’s admin team need to participate?
- What’s the freshness expectation, and does polling meet it?
- What’s the failure mode if VOMO is unavailable or rate-limited?
Where to go next
Polling and Sync
The change-detection patterns that compensate for the lack of webhooks.
The Volunteer Data Model
The full data model — useful for understanding what’s read-only vs. write-capable.
API Performance Tips
The caching patterns that make read-heavy workflows scale.
Sync Architecture Patterns
The broader architectural patterns for read-source-and-sync designs.