The interactive endpoint pages in the docs — send real requests to CRM+, Raise, and Volunteer endpoints, see real responses, and copy the generated code into your project in your language of choice
The Virtuous API Docs include an interactive API Playground — every endpoint page lets you send real requests to the API, see real responses, and copy the resulting code into your project. Instead of reading a static reference page and then guessing how the request actually looks, you compose the request in the browser, fire it, and see exactly what happens.For partners building integrations, this is one of the most useful features in the docs: it collapses the gap between reading reference material and writing the actual code.
Most Virtuous endpoints require authentication. The Playground supports this directly — you provide a token, the Playground includes it in the request, and you get a real authenticated response.
Use sandbox or test credentials in the Playground. The Playground sends real requests to the API — if you use production credentials, you’ll affect production data. For exploration, debugging, and learning, sandbox credentials are the right tool. If you’re a partner in the Integration Pathway, you’ve been provisioned a sandbox specifically for this.
So you don’t have to re-paste it for every request
The token is sent in the request
Standard Authorization: Bearer <token> header (or whatever the endpoint requires)
Your credentials aren’t sent anywhere else
The Playground forwards your request to the API directly (or via a proxy when configured) — no third party sees the credentials
Despite the storage convenience, treat the Playground like any other tool that handles your credentials — don’t paste tokens for accounts you don’t own, and clear stored tokens when you’re done.
When the OpenAPI spec includes example values, the Playground typically prefills the form with those examples. This means for many endpoints, you can hit Send immediately with no edits and see a working response. From there, modify parameters to explore different cases.
The Playground may show only required parameters by default, with optional parameters available behind a “Show optional” toggle. This keeps the form focused for quick exploration; expand it when you need to test edge cases.
The response viewer formats JSON cleanly so you can read the actual field shape, nesting, and types — useful when the docs describe a resource and you want to see exactly what it looks like in practice.
Beneath each Playground request is generated code that recreates the request you just configured. The code is generated based on the parameters you’ve filled in — change a parameter, and the code updates.
The Playground is generated from the OpenAPI specifications published with the docs. This means:
What you see in the Playground
Where it comes from
The list of available endpoints
The OpenAPI paths definitions
Each endpoint’s parameters
The OpenAPI parameters and requestBody
Validation hints (required, types, formats)
The OpenAPI schema definitions
Example values for prefilling
The OpenAPI examples and example fields
Response shapes
The OpenAPI response schemas
When you want to see the full OpenAPI spec for a product, the AI Assistant can read it directly. You can also access the spec for direct inspection through the docs site’s OpenAPI integration.
A reality worth knowing: the OpenAPI specs have some documented quirks (see audit findings referenced throughout the Concepts and Workflow pages). When the Playground shows spec-based information that differs from observed live behavior, the docs’ inline annotations call this out.When in doubt, trust the live response over the spec description. The Playground shows you the real API behavior; the spec is the documented expectation.
