Breaking changes for Volunteer API

Lindsey Rix

Breaking changes we previously announced are now live.

GetJobById

For Get volunteer job by ID, we're now returning string descriptions instead of integer IDs for the following fields.

Field	Before	After
category	integer (ID)	string (description)
volunteer_type	integer (ID)	string (description)

These fields were always intended to return human-readable values. This fix corrects the original behavior so you no longer need to make additional calls to resolve IDs to descriptions.

GetVolunteerAssignments

For Get assignments for a volunteer, the following fields now reflect the volunteer's assignment dates instead of the job dates.

Field	Before	After
start_date	Job date (JOB.START_DATE)	Assignment date (FROM_DATE)
end_date	Job date (JOB.END_DATE)	Assignment date (TO_DATE)

Assignment dates more accurately represent when a volunteer was active. To retrieve job-level dates, use the new job_start_date and job_end_date fields.

GetJobVolunteersByJobId

For Get volunteers assigned to a specific job, the id field is now explicitly the assignment ID, and three new fields have been added to the JobVolunteer response.

Field	Change
id	Clarified as assignment ID, not volunteer ID
constituent_id	New - Returns the constituent record ID
start_date	New - Returns the assignment start date
end_date	New - Returns the assignment end date

The previous id field was ambiguous. These updates make it easier to identify both the assignment and the constituent without additional lookups.

GetVolunteerEmergencyContact

For Get emergency contact for a volunteer, when a constituent exists but has no emergency contact data, the endpoint now returns 200 with empty fields instead of 404.

Scenario	Before	After
Constituent exists, no contact data	404 Not Found	200 OK with empty response body
Constituent does not exist	404 Not Found	Unchanged - 404 Not Found

A 404 response previously made it impossible to distinguish between "constituent not found" and "no emergency contact on file." This change follows standard API conventions so you can handle both scenarios reliably.