Integrating with SpendOne
SpendOne is the AI-based platform for indirect corporate spend: everything a company buys outside direct materials (software subscriptions, travel, services, marketing, facilities), from the first request through approval, ordering, invoice processing and the export into the general ledger.
This documentation is for engineers connecting a customer's systems to SpendOne. Identity providers, HR systems, ERPs, accounting systems, data warehouses and internal tooling all meet SpendOne at the same REST API, described in full in the API reference.
Start here
- API Basics: authentication, the base URL, the response envelope, pagination, errors. Read once; it applies to every endpoint.
- Core Concepts: the object model your integration writes into: legal entities, organizational units, cost centers, users, roles and permission sets, and the spend lifecycle they hang off.
- An integration scenario: the four below cover what most integrations actually need.
Integration scenarios
| Scenario | What it covers |
|---|---|
| Push users and permissions | Keep the SpendOne directory in step with your HR system or IdP: users, org units, cost centers, permission sets |
| Pull audit logs | Stream the append-only trail of every state change into a SIEM or archive |
| Pull invoice data | Read invoices, their booking proposals and the journal entries behind them |
| Push documents and spend | Feed invoices, quotes and purchase requests into the platform from an upstream system |
The two ways data comes in
Both are covered by their own guide, and most customers use both:
- Data import via blob storage: your ETL drops CSV files into a write-only landing zone; a worker picks them up, validates them and reports per-row outcomes. This is the bulk path for master data: users, org units and cost centers, suppliers, general-ledger accounts.
- The REST API: record-by-record reads and writes, for corrections, for event-driven pushes, and for everything the import kinds do not cover.
Orders are the exception to both: a procurement platform that raises and approves requisitions itself (Ariba, Coupa, JAGGAER, Oracle, Workday) delivers them as cXML, over its own endpoint and its own credential. See cXML punchout orders.
For a directory owned by an identity provider there is a third path, SCIM 2.0, which is the right answer whenever your IdP is the system of record for joiners, movers and leavers.
Identity
SSO and user provisioning covers how people sign in (OpenID Connect, brokered by Zitadel, with your own IdP federated in) and how their records get created (SCIM, CSV import, or direct API calls). Integrations themselves do not sign in interactively; they authenticate with a bearer token, described in API Basics.
Getting a customer live
Customer Onboarding is the runbook: the fixed sequence of milestones from an empty tenant to production, which of them block the others, and the endpoint sequence for each.
Reference
- API reference: every published endpoint, parameter and schema.
- Problem types: every error the API can return, with its status and extension fields.
- Downloads: the OpenAPI spec and a generated Postman collection.