
Cubbie is a B2B software marketplace where companies discover, buy and manage the software they run on. The management side keeps a company's whole stack in one place: what they own, what it costs, when it renews, and who is actually using it.
The Halo integration adds the seat picture. A mutual customer connects their own Halo instance using a read-only API application they create themselves, and Cubbie reads the agent roster to show how many agent seats exist and how many of those agents are inactive. That sits alongside every other tool in their stack, so an admin preparing a renewal sees Halo in the same view as everything else instead of opening a separate console.
It is deliberately narrow. Cubbie reads the agent roster and nothing else: no tickets, no billing, no end users, no customer data. Nothing is written back to Halo.
- Agent seat count. Cubbie reads your Halo agent roster and shows the number of agent seats on your Halo record in Cubbie, next to every other product in your stack.
- Inactive agents counted separately. Agents flagged inactive or disabled are reported on their own, so you can see the gap between the seats you hold and the seats in use before a renewal comes up.
- You own the credentials. You create a read-only API application inside your own Halo instance, under Configuration then Integrations then HaloPSA API, using the client credentials login type, and paste the client ID and secret into Cubbie with your instance URL. Nothing has to be provisioned on Halo's side.
- Read-only by design. The integration calls two endpoints: the token endpoint and GET /api/Agent. It requests the narrow read:agents scope, never writes to Halo, and never reads end users, tickets or billing.
- Covers both products. The same integration supports HaloPSA and HaloITSM. - Credentials encrypted at rest, and the access token is short lived and held only for the duration of a sync.