Skip to main content
Forms in the Volunteer API are data-collection templates — waivers, volunteer applications, signup questions, post-event surveys. When a volunteer fills out a Form, the result is a Form Completion containing the volunteer’s responses to each field. The chain is:
This page covers the five-resource Form family, the three read endpoints, and the practical patterns for working with form data — including the audit-flagged quirks in the spec.

The three endpoints

All Form endpoints are read-only. Forms are created and managed in the VOMO admin UI; volunteers submit Form Completions through the VOMO UI; partner integrations consume the data.
⚠️ Spec gap (audit #20): The path parameter for the third endpoint is {completion} rather than the more conventional {completionId}. The parameter descriptions in the spec also contain typos (“VOMO From ID” instead of “VOMO Form ID” — audit #19). The path works as documented; the names will be cleaned up in a future spec revision.

The Form family of resources

The Form resource family has five distinct schemas, each capturing a different layer:

FormResource — the template

The top-level Form record describing the data-collection template:
⚠️ Spec gap (audit #17): The FormResource schema is incorrectly typed as array in the spec. The actual resource is a single object — the field set above is on the items inside that erroneous array. Code generated from the spec may need manual adjustment.
⚠️ Spec gap (audit #15): The slug field is documented with two contradictory pieces of information:
  • An enum: ['SHORTTEXT', 'LONGTEXT', 'DROPDOWN', 'MULTIPLESELECT', 'WAIVER', 'TEXTSINGLE'] (these look like form-field types)
  • An example: "2d8614a5-31ed-4810-8da2-448f59463e43" (a UUID)
The enum and example can’t both be right. The example suggests the slug is a UUID identifier for the Form; the enum looks like it was copy-pasted from a Form Field’s field_type. Treat the slug as a UUID string per the example. The enum will be removed in a future spec revision.
⚠️ Spec gap (audit #16): The id field has minimum: 3, maximum: 45 constraints — these are string-length-style constraints applied to an integer ID. The actual ID range almost certainly isn’t 3 to 45; treat IDs as unconstrained integers.

FormFieldResource — the questions

Each Form has an array of Fields — the individual questions the volunteer answers:
⚠️ Spec gap (audit #17): FormFieldResource is also typed as array in the spec — same issue as FormResource.

FormFieldOptionResource — dropdown choices

For Fields with field_type of DROPDOWN or MULTIPLESELECT, the available options: The weight field controls display order. Lower weights appear earlier in the list.

FormCompletionResource — a volunteer’s submission

When a volunteer completes a Form, a Form Completion record is created: This is the central “what did this volunteer say in this form” record. The field_responses array captures the actual answers.

FormFieldResponseResource — a single answer

Each entry in field_responses represents one Field’s answer: Even numeric or boolean Field values come back as strings. Parse them based on the Field’s field_type when displaying or processing.

Form types

The form_type enum determines what context the Form is used in:
⚠️ Spec gap (audit #54): The spec documents only PROJECT as a valid form_type value. Other types likely exist in production (organization-wide signups, user-profile forms, etc.) but aren’t documented. Treat unknown values gracefully — log them but don’t crash.

Field types

The field_type on a Form Field determines what input the volunteer provides. Likely values (from the Form slug enum, which appears to have been miscategorized — see audit #15): For partner integrations parsing Form completions:
JavaScript
The exact storage format for MULTIPLESELECT (comma-separated vs. JSON array vs. something else) isn’t documented in the spec; the pattern above handles the most likely formats defensively.

Listing forms

cURL

Available filters

⚠️ Spec gap (audit #18): The include_archived parameter is typed string in the spec but is functionally a boolean — accepts "true" or "false". Code should send the boolean as a string ("true" / "false").

Common list patterns

Active Forms only:
JavaScript
Find Forms by name:
JavaScript
Recently-updated Forms (for change detection):
JavaScript
Useful for polling integrations that watch for Form structure changes.

Reading Form completions

cURL
Returns all completions of Form #789, paginated.

Available filters

Common list patterns

Completions for a specific user across one form:
JavaScript
All completions since the last sync:
JavaScript
A polling integration pulling form completions on a schedule would iterate over active Forms, then for each Form pull new completions since the checkpoint.

Fetching a single completion

cURL
Returns a single FormCompletionResource with full field_responses[]:
JavaScript
The list endpoint already returns completions with their field responses, so the single-completion endpoint is most useful for re-fetching a specific completion when you have the ID but not the cached data.

Reading field responses with the Field definitions

A common pattern: display a Form completion alongside the Field definitions so the responses make sense in context.
JavaScript
The result is a displayable Form Completion with question text, field type, and parsed value for each response — what you’d show in a UI showing “Bruce Wayne’s volunteer application.” For partner integrations doing this frequently, cache the Form definitions — they change rarely and the lookup happens often.

Common workflows

Sync Form completions to an external system

For partner integrations syncing volunteer applications, waiver acceptances, or survey responses into an external CRM:
JavaScript
Run this on a schedule per Form the customer wants synced.

Build a per-user form history

For showing a single user’s full form submission history:
JavaScript
This is N+1 (one Form list + one Completion list per Form). For accounts with many Forms but where most users have few completions, this is acceptable; for high-volume accounts, consider caching.

Detect waiver expiration

For organizations requiring annual waiver renewal:
JavaScript
The result is a list of users whose waiver completion has aged out — candidates for renewal outreach.

Aggregate Form responses for reporting

For survey or feedback Forms:
JavaScript
Useful for survey-style reports: “12 volunteers said yes, 3 said no, 5 left it blank.”

What can’t be done via the API

If a partner integration needs to push Form data into VOMO (e.g., importing waivers signed externally), coordinate with VOMO’s admin team for an alternative path — typically a CSV import. See Understand Write Limitations.

A reference Forms client

JavaScript
The parsers handle the defensive cases — missing optional fields, the array-vs-object schema confusion (audit #17 affects the top-level FormResource and FormFieldResource but doesn’t reach parser logic if you treat the response as the array-of-one-record it sometimes appears as).

Where to go next

Certificates

The other read-only resource — training and achievement credentials.

Users

Users complete Forms; the user_id is the linkage to Form Completions.

Projects and Project Dates

Forms are typically attached to Projects.

The Volunteer Data Model

The full data model context for Forms.
Last modified on May 22, 2026