API & webhooks

Build on an Open Integration Layer

Bespoke needs will always exist. An open interface means they do not require a platform change request.

The business problem

Closed platforms become bottlenecks

When every integration requires vendor development, simple requirements — a tenant portal, an internal report, a link to a specialist system — wait in a roadmap queue. Organisations then build shadow spreadsheets to work around their own platform.

Integrations dependent on vendor development capacitySimple requirements waiting on a roadmapShadow spreadsheets filling the gapsNo way for partners to build alongside the platform

The IntelliGrid approach

Documented interfaces your team or partners can build on

IntelliGrid exposes an integration layer covering the core operational objects, with authenticated access and event webhooks so external systems can react to what happens rather than polling for changes.

Authenticated REST access to core objectsEvent webhooks for work order and asset changesScoped credentials per integrationDocumentation provided to authorised partners

Availability

Interface specifications are released under agreement

This page describes the integration architecture and the scope of available interfaces. Endpoint specifications, authentication detail and environment access are provided to authorised integration partners and customers under agreement rather than published publicly.

To request technical documentation or discuss a specific integration, contact partners@intelligrid.asia.

Scope

What the integration layer covers

Authentication

Scoped, revocable credentials issued per integration.

Work orders

Create, read and update work in external systems and portals.

Assets

Read and maintain asset, location and condition data.

Users

Provision and manage users and permissions from an external directory.

Events

Event stream covering status changes on core objects.

Webhooks

Outbound notification so external systems react rather than poll.

IoT telemetry

Ingest readings from devices and platforms not natively integrated.

Environments

Separate test and production environments for integration development.

Workflow

Building an integration

STEP 1

Request

Integration scope discussed and documentation issued.

STEP 2

Credentials

Scoped access provisioned in a test environment.

STEP 3

Build

Integration developed against documented interfaces.

STEP 4

Validate

Behaviour and data verified before promotion.

STEP 5

Operate

Production credentials issued and interface monitored.

Business benefits

Bespoke requirements delivered without a roadmap wait Partners able to build alongside the platform Event-driven integration rather than polling Scoped credentials limiting integration blast radius Test environments separated from production data