VAN’s Event Calendar system is used to track the participation of your volunteers, members, and activists at calendar events. Organizers use this system to track events like House Parties, Campaign Rallies, Phone Banks, and more. The Event system is designed to allow some campaigns and organizations a high degree of complexity, but is easily scalable down to the local level where such sophistication may be less desired. This varying degree of sophistication is facilitated by Event Types which allow users to set defaults for which Roles are available for volunteers, how many Locations the event has, whether volunteers may sign up for multiple Shifts, and more. Use this endpoint to create, update, and delete specific Events, and to find existing Events.

See Event Types for additional information about Event configuration rules.

Use the Signups endpoint to record a person’s participation at Events.


A Note About Dates and Times

Dates and Times in Event-related endpoints are ISO 8601 formatted and respect UTC timezone offsets (which are similar to time zones). If no UTC offset is specified, the target context’s default timezone offset is used. In cases where an endpoint expects a time property, the input should still be in the form of a date and time. The system will simply ignore the date portion of the value.

Additionally, dates must always be in the 20th or 21st century (01 Jan 190001 Jan 2100).


A Note About Simple Objects

Events are often related to other objects exposed by the API. Some of these objects are simply referenced by—but not modified by—the Events endpoint. References to these objects use a minimal, or Simple representation of the object; if a type is described as simple, the only requirement when sending a request is the unique identifier for that object (e.g., the simple Event Type object only has an eventTypeId property). Other properties, if specified, will be ignored.

In some cases, the Events endpoint will also return a simple object. In this case, it is typically just the unique identifier and the name for that object.

The Common Models section below indicates the full representation of the object as it would appear in a GET request. However, when POSTing or PUTting Events, the simple representation of the object is sufficient. For example, when creating an event with a single Location, it is sufficient to provide the locationId of the existing Location, rather than a full representation of that Location.


A Note About String Properties

String properties of Events and related objects use standard input validation rules.


A Note About Recurring Events

Recurring Events cannot be created via the API. However, Recurring Events created via the VAN UI can be retrieved and queried for. Additionally, you can update and delete individual instances of a Recurring Event.