SpendInt APIs
SpendInt APIs are inbound REST APIs that enable external procurement systems to send catalog, pricing, order, shipment, and invoice data into ServiceNow Sourcing and Procurement Operations, synchronizing structured procurement data from third-party systems.
The SpendInt API is part of the Source-to-Pay Integration Framework and is provided in the sn_spend_intg namespace. It supports data-level, asynchronous integrations where third-party external systems send updates to
ServiceNow after data changes occur in the source system.
SpendInt API purpose and usage
SpendInt APIs are appropriate when procurement data is created or managed outside ServiceNow and must be pushed into ServiceNow to support purchasing, fulfillment, and financial workflows.
Supported inbound data scenarios and APIs
Each inbound procurement scenario is handled by a dedicated SpendInt endpoint under the /api/sn_spend_intg/spendint path.
| Data scenario | Purpose | SpendInt API |
|---|---|---|
| Catalog ingestion | Create or update supplier products, product models, categories, and related attributes | POST /sn_spend_intg/spendint/catalog |
| Price updates | Update pricing for existing supplier product records | POST /sn_spend_intg/spendint/price |
| Availability updates | Update product availability or stock information | POST /sn_spend_intg/spendint/availability |
| Order acknowledgements | Send order confirmation details after a purchase is submitted | POST /sn_spend_intg/spendint/orderack |
| Shipment updates | Send shipping and delivery status for orders | POST /sn_spend_intg/spendint/shipment |
| Invoice ingestion | Send invoice data generated in third-party external systems into ServiceNow | POST /sn_spend_intg/spendint/invoice |
For details about individual APIs, request payloads, and field mappings, see Spendint API.
How SpendInt APIs process data
SpendInt endpoints receive inbound payloads and write them to integration staging tables managed by the Source-to-Pay Integration Framework. The framework then validates and transforms the data into the appropriate procurement records, such as products, orders, shipments, or invoices.
This design separates data ingestion from record creation, allowing consistent handling of supplier data across integration scenarios.