Every integration on this page is built on the same API you get.

CubeMSP and REST API & Webhooks

A documented REST API and webhooks on every meaningful event - included in the platform, not licensed per connection.

There is a familiar and unattractive commercial pattern in this market: the platform is sold, and then the ability to get data in or out of it is sold again, per connection, per year. We do not do that. Every integration described elsewhere on this site is built against the same documented REST API that ships with your tenant, authenticated the same way, rate-limited the same way. If we can build against it, so can you, or so can whoever you employ to.

What moves

Exactly what is synced, and which way

Being specific about this up front avoids the single most common integration disappointment - discovering after go-live that one field never travelled.

  • Both ways

    Clients, contacts and sites

    Read and write the client structure, so another system can create a client or keep contact details in step without a manual step.

  • Both ways

    Incidents and time entries

    Raise, update, resolve and query incidents, and book time against them. This is the endpoint most integrations use.

  • Both ways

    Services and quantities

    Read the recurring book and write quantity changes, which is how licence reconciliation and provisioning tools plug in.

  • Out of CubeMSP

    Webhooks on every meaningful event

    Incident raised, assigned, resolved; service changed; renewal approaching; review published. Delivered with retries and a signature you can verify.

How it behaves

The detail that decides whether it is actually useful

  • Documented, with examples

    An OpenAPI description and worked examples, not a PDF from two versions ago. If the documentation is wrong, that is a defect and we treat it as one.

  • Scoped keys

    API keys scoped to your tenant with per-endpoint permissions, so an integration that only needs to raise incidents cannot read your margins.

  • Signed, retried webhooks

    Payloads signed so you can verify they came from us, and retried with backoff so a brief outage at your end does not lose an event.

  • Not licensed per connection

    No per-connector charge and no integration tier. Charging separately for access to your own data is a business model we have chosen not to have.

Setting it up

Three steps, done during implementation

  1. Create a scoped API key in your tenant and grant it only the endpoints it needs.

  2. Register webhook endpoints and verify the signature on the test event.

  3. Build against the sandbox tenant before pointing anything at live data.

Questions

What people ask about this one

  • Yes, in every tenant, at no additional charge and with no per-connection licence. This is a deliberate commercial position rather than an oversight we will correct later.

  • Yes - a separate tenant with representative data, so integrations are built and tested without touching live client records.

  • Versioned endpoints with a deprecation policy. Breaking changes are announced with notice and the previous version keeps working through the transition.

  • Generous enough that normal integration work never encounters them, and published rather than discovered. If you have a legitimate bulk requirement, tell us and we will raise them rather than making you work around them.

  • Yes, in full, at any time, in open formats. There is no commercial advantage in holding a customer’s data hostage and we do not design as though there is.

API

Check the API detail before you commit

Send us the specifics - your chart of accounts, your tax treatment, your product structure - and we will tell you exactly how it maps rather than promising it will be fine.