API
API Documentation
Customer-facing API principles, authentication, versioning, and webhook guidance for Xpitro integrations.
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.
Related articles
Was this helpful?