Skip to content

API

Integrations

How to plan, secure, and govern integrations that extend Xpitro workflows without bypassing them.

Updated Jul 20, 20262 min read
On this page

Purpose

This guide introduces the customer-facing integration posture for Xpitro.

Integration Philosophy

Xpitro integrations should extend governed workflows, not bypass them.

The best integrations:

  • respect organisation boundaries;
  • use supported APIs and interfaces;
  • improve operational flow between systems;
  • preserve auditability and control.

Common Integration Use Cases

Customers may use integrations to:

  • exchange data with adjacent internal systems;
  • connect customer workflows to reporting or export pipelines;
  • automate routine synchronisation or notifications;
  • support partner or multi-system operational models.

Integration Readiness Checklist

Before building or enabling an integration, confirm:

  1. the business problem the integration should solve;
  2. the organisation and user scope;
  3. whether API or integration access is included in your plan;
  4. how errors, retries, and failures will be handled;
  5. who owns the integration on the customer side.

Example Request

A typical authenticated request to a customer-facing endpoint looks like this:

terminal
curl -X GET "https://api.xpitro.com/v1/organisations/me" \
  -H "Authorization: Bearer $XPITRO_API_TOKEN" \
  -H "Accept: application/json"

Which returns:

response.json
{
  "id": "org_01h9x8k2p3q4r5s6t7u8v9w0",
  "name": "Acme Compliance Ltd",
  "plan": "professional",
  "createdAt": "2026-04-11T09:32:00Z"
}

Security And Governance

Treat tokens as secrets

API tokens are scoped to your organisation. Never embed them in client-side code, commit them to version control, or share them outside your integration owner group.

Integrations should be designed with:

  • least privilege;
  • explicit ownership;
  • auditable behaviour;
  • safe retry handling;
  • controlled data sharing.

Build Vs Buy Decisions

Customers evaluating custom integrations should consider:

  • whether the workflow already exists natively in Xpitro;
  • whether a lighter export or reporting approach is enough;
  • whether a partner or managed integration approach is more appropriate than direct build work.

Support Boundary

Xpitro can support supported product surfaces and documented integration behaviour. Customers should not rely on undocumented internal interfaces as if they were public contracts.