Skip to main content
Projects and Project Dates are two distinct concepts that often get confused. A Project is the template — the volunteer opportunity itself, describing what’s being done, where, by whom, with what policies. A Project Date is one specific scheduled occurrence — Saturday March 15, 9am to 1pm, at this address, with these participants. This page covers both resources in detail: the field shapes, the endpoints, the relationship between them, and the practical patterns for reading and managing them.

Project vs. Project Date — the mental model

The clearest analogy is a recurring meeting:
The Project carries the long-lived information — name, description, address, eligibility rules, designated organizers. The Project Date carries the per-occurrence information — start time, end time, participants who actually showed up.

The Project endpoints

Two paths in this list relate to Project Dates (/projects/today and /projects/date/{id}) rather than Projects themselves. The next sections distinguish them.
⚠️ Spec gap (audit #34): The endpoint GET /projects/date/{id} has an unconventional path (verb-like singular noun in the middle). The audit recommends renaming to GET /projects/{projectId}/dates/{dateId} in a future spec revision. For now, use the documented /projects/date/{id} path.

The Project resource

List shape (ProjectResource)

GET /projects returns an array of ProjectResource objects — the metadata describing the volunteer opportunity:
⚠️ Spec gap (audit #42): ProjectResource defines both name AND project_name as separate properties with identical descriptions. This is a duplicate field — consumers can’t know which to use. Use name (which aligns with other Virtuous APIs); treat project_name as a deprecated alias likely to be removed.
⚠️ Spec gap (audit #43): ProjectResource.address is typed array in the spec, but an address is conceptually a single object (street, city, state, etc.), not a collection. The live API likely returns an object; code should parse it as such regardless of the spec’s declaration.

Detail shape (ProjectDetailResource)

GET /projects/{id} returns a ProjectDetailResource — a superset of ProjectResource plus the operational policy fields: The all_dates and next_date fields are particularly useful for partner integrations — they let you read the Project’s schedule without separate Project Date fetches.

Listing projects

cURL

Available filters

The dates_before and dates_after filters are distinctive — they filter Projects by the timing of their Project Dates, not by the Project’s own creation or update time. Useful for “Projects with shifts coming up this month” queries.

Common list patterns

Currently active and published projects:
JavaScript
Projects with shifts in the next 30 days:
JavaScript
Projects for a specific organization within the family:
JavaScript

Fetching a single project

cURL
Returns a ProjectDetailResource with full policy fields and scheduled dates.
JavaScript
The detail response is useful when you need policy info (age limit, background check requirement) along with the schedule.

Creating a project

cURL
⚠️ Spec gap (audit #31, #32, #33): The POST /projects request body is defined as an anonymous inline object in the spec (not a named schema), and PUT /projects/{id} contains many field descriptions that are literal placeholder text ("Update Project"). The exact valid field set, validation rules, and create vs. update field differences aren’t well-documented.For production use, confirm the field set against the live API by inspecting actual create responses or by coordinating with VOMO support.
A successful create returns the new Project. Capture the id for subsequent updates.

Updating a project

cURL
PUT /projects/{id} is a full replacement — the request body must contain every field that should persist. Fields omitted from the request may be set to default values or null.

The GET-then-PUT pattern

For partial updates, fetch the current record, modify the fields you need, then PUT the full record back:
JavaScript
The pattern is common in REST APIs without PATCH support. The cost: an extra read per update. For high-frequency update workloads, this can add up — see API Performance Tips for caching patterns.

Project Date endpoints

Two endpoints expose Project Dates: There’s no GET /project-dates/{id} or similar — Project Dates are accessed through the Project path or through “today” view only.

GET /projects/today

Returns a list of HappeningResource objects — Project Dates scheduled for today:
This is the “what’s happening today” feed — useful for daily-summary dashboards, day-of-event reports, and check-in tools.
The VOMO term “Happening” is used internally for a Project Date. HappeningResource is the schema; Project Date is the conceptual name. Both refer to the same thing.

GET /projects/date/{id}

Returns a specific Project Date with full detail including the participants:
JavaScript
⚠️ Spec gap (audit #4): The GET /projects/date/{id} response uses empty schema: {} in the spec. The response shape is documented only through inline examples — the exact field set is not formally specified. Build parsers from the actual response shape.

Participants on a Project Date

The participants embedded in a Project Date response use the Participant schema: Participant is the display representation; ParticipationResource (returned on UserDetailResource.participations) is the record representation with timing and verification details. The two are related but distinct.

Common Project workflows

Build a “today” dashboard

JavaScript
Useful for displaying “what’s happening today” in a partner-built dashboard.

Pull a Project’s full schedule

JavaScript
The all_dates field on ProjectDetailResource provides the full schedule without separate Project Date fetches.

Find Projects with capacity

JavaScript
For partner-built “find a project to volunteer for” interfaces — surface only Projects with available spots.

Sync Projects to an external system

JavaScript
The updated_after filter combined with links.next pagination produces a clean incremental sync.

What can’t be done via the API

Most of these are intentional — they preserve the customer’s organizer-controlled scheduling and check-in workflow. Partner integrations that need to push participation data into VOMO should coordinate with VOMO’s admin team for alternative paths. See Understand Write Limitations.

A reference Project client

JavaScript

Where to go next

Groups

The User-organizing resource — Groups and Group Members.

Users

The User resource — including the participations embedded in user details.

The Volunteer Data Model

The full data model context.

Create or Update a Project

The workflow walkthrough for Project writes.
Last modified on May 22, 2026