The VolunteerHub Open API is a REST-based API that allows third-parties to access raw VolunteerHub data for the purposes of application integration.
You can access the Open API resource page in your site by entering /openapi at the end of your site's URL (e.g., "YOURORG.volunteerhub.com/openapi").
- At the top of the resource page is an open API file you can use to create custom connectors with applications like Microsoft Flow.
- Lower on the page, use the interactive endpoint/parameter fields to build and test a query in the resource page without writing a single line of code.
By default, only VolunteerHub "superusers" are configured for API access. This is typically sufficient for applications such as data synchronization, offline report generation, or control panels giving an overview of VolunteerHub activity.
Any Superuser in a VolunteerHub site has access to the API free of charge, but we do not provide assistance in the configuration or maintenance of your use of this tool.
All endpoint urls are formed by appending the relative url for the desired endpoint onto the secure sockets layer (SSL) url for the organization's VolunteerHub site. For example, if the VolunteerHub site is typically accessed using:
Then, its SSL url would be:
A list of events could then be retrieved via the url:
For a complete list of available endpoints, click here.
Note that SSL connections are required because of the use of basic authentication for user identification (see below). The API will not respond to non-SSL requests.
User identification is provided by basic authentication over SSL, and therefore all requests must include a valid. To compute the appropriate value for the Authorization header, use the following pseudo-code:
For example, if the username is "jsmith" and the password is "1234" then you would include the following header with your request:
A detailed discussion of basic authentication is beyond the scope of this manual--pleaseas a starting point for further details.
Because API responses are text-based and contain repetitive formatting, they are usually quite compressible. Because of this, HTTP compression can be employed to reduce the size of such responses by as much as 80%, greatly reducing transfer time and increasing performance. If your webservice client supports it (most do), you can enable HTTP compression by including thein your request. For example, the following header will return the response using either gzip or deflate compression:
Although highly recommended, HTTP compression is optional. If the Accept-Encoding header specified above is omitted, responses will be sent using standard uncompressed text.
Response format (JSON/XML)
Responses can be returned in either JSON or XML format. By default, responses are returned in JSON format; if this is the desired format then no further action is required. To receive responses in XML format, simply include the followingwith your request: