Skip to content

API

API Documentation

Customer-facing API principles, authentication, versioning, and webhook guidance for Xpitro integrations.

Updated Jul 20, 20262 min read
On this page

Audience

This guide is for customers and integration teams evaluating or using Xpitro APIs.

API Principles

Xpitro APIs are intended to support controlled, organisation-aware integrations. API access is governed by:

  • your plan and entitlement model;
  • your organisation and user permissions;
  • the current product and integration state.

What To Expect

Customer-facing APIs typically fall into these categories:

  • customer and account context;
  • workflow or domain data access;
  • reporting or export access;
  • integration and automation support;
  • webhook or event-driven integration scenarios, where available.

Authentication And Access

API access is not assumed for every customer or every user.

Before integrating, confirm:

  • whether API access is included in your plan;
  • which environment and credentials you should use;
  • which organisation context the integration should target;
  • who in your organisation will own the integration.

Integration Design Guidance

Good integration practice includes:

  • designing for the correct organisation context;
  • using least privilege;
  • handling failures and retries safely;
  • validating payloads and responses;
  • avoiding assumptions about unsupported endpoints or fields.

Versioning And Stability

Customers should treat the published API documentation and current product release behaviour as authoritative for supported integrations.

Do not build against:

  • internal controller names;
  • internal data models;
  • unpublished or undocumented endpoints;
  • implementation details from engineering specs.

Webhooks And Events

Where webhook or event-driven integration is available:

  • treat Xpitro as the system of record for its own governed state;
  • validate signatures and authenticity where applicable;
  • design for idempotency and replay safety;
  • avoid assuming event order beyond documented guarantees.

Support Expectations

For API or integration support, provide:

  • the affected endpoint or integration flow;
  • request identifiers where available;
  • timestamps;
  • the organisation and environment involved;
  • reproduction steps and payload examples where safe to share.

Current Documentation Boundary

This customer guide establishes the outward-facing API expectations and usage model. A fuller endpoint-level developer portal or reference can be layered on top of this foundation as the external integration surface is formalised.