Skip to main content

​
Why a custom playground

GET /variables doesn’t have a static Mintlify OpenAPI playground here, on purpose: its filter parameters aren’t confirmed yet (see Discovery Endpoints), and the option values for each filter come from a different, live endpoint — GET /variable/get-variable-filter-data — rather than a fixed enum. A static OpenAPI spec can’t express “fetch the real choices at request time,” so this page does it with a small React component instead.
This tool runs entirely in your browser. Your token is never sent anywhere except directly to api.communityhub.cloud — but treat it like any other credential, and don’t paste a token you don’t want visible in browser dev tools. It also requires api.communityhub.cloud to allow cross-origin requests (CORS) from this docs site; if that isn’t enabled yet, the requests below will fail with a CORS error rather than a normal API error.
If this site’s login is wired up to auto-fill your token (via Mintlify’s JWT/OAuth authentication + a user object with a content.token or apiPlaygroundInputs.header.Authorization value), the field below fills in automatically once you’re signed in. Until that’s wired up on the backend, paste your token manually — see Authentication for how to generate one.

​
What this proves — and what it doesn’t

This confirms the shape of a working filter flow: fetch facets live, let a user pick values, build a request from those picks. It does not confirm that GET /variables actually accepts resourceType, pointType, buildingType, building, status, and dataReception as query parameter names — those are still the same unconfirmed guesses flagged in Discovery Endpoints. Use this tool against a real token to find out, then update this page’s parameter names (and the static openapi.json) to match once confirmed.