> ## Documentation Index
> Fetch the complete documentation index at: https://www.composer.id/llms.txt
> Use this file to discover all available pages before exploring further.
# Basware
> Basware (Procurement Orchestration): the API posture, publish target and field mapping composerID publishes a decision reference through.
This page records how composerID publishes into Basware: the vendor's API posture, the publish target and field mapping, and the documentation each claim rests on. It is for anyone evaluating the connection or building against it.
Basware is a purchase-to-pay and accounts-payable automation platform: purchase requisitions and orders, goods receipts, invoices and matching against orders, with REST APIs (Purchase, Invoice, Matching, Master Data) published on the Basware Developer Portal. Services and outsourced spend are executed as purchase documents rather than VMS work orders, so Basware is the system of execution for statement-of-work and managed-service decisions, not a VMS. composerID publishes the approved services decision as a Purchase API document and carries the Intent ID in the header's client-supplied externalCode, the same key Basware uses to identify externally sourced documents, then reads the order and its matched invoices back by that code.
Category: Procurement Orchestration. Coverage status: Specification mapped. Vendor documentation: public developer portal.
## Integration path
How composerID connects to this destination, at a glance.
| Step | Detail |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Authentication | OAuth 2.0 client credentials: Basware provisions the client ID and secret per customer tenant (or certified partner) rather than through self-service signup, and every call carries the bearer token. |
| composerID publishes | Purchase document (services): Purchase API: purchase order import (externally sourced order); purchase requisition create where the tenant's API version supports it |
| Intent ID lands on | `purchase_order` `externalCode`, written into the destination record |
| Back-sync | Polling: the destination publishes no events composerID can subscribe to, so state is read back on a schedule. |
## Vendor documentation
## API posture
| Aspect | Detail |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Authentication | OAuth 2.0 client credentials: Basware provisions the client ID and secret per customer tenant (or certified partner) rather than through self-service signup, and every call carries the bearer token. The token endpoint and any scope names are indicative until confirmed at onboarding. |
| Style | REST over HTTPS with JSON bodies. Imports on the Purchase and Master Data APIs are accepted and processed asynchronously (the document is validated on receipt, then applied), so composerID reads the object or its processing status back rather than assuming a synchronous create. Pagination and filter parameters are indicative until confirmed against the tenant's API version. |
| Base URL | [https://api.basware.com](https://api.basware.com) (versioned paths, v1 at the time of writing; test and regional hosts exist, so confirm the tenant's environment at onboarding) |
| Webhooks | Not relied on. Basware's portal lists a notification capability for document events, but its coverage of purchase documents could not be verified offline, so composerID treats Basware as poll-first: it reads purchase orders and matched invoices back by externalCode on a schedule, and enables push only once the tenant confirms the event types it can deliver. |
| Events posture | Polling |
| Rate limits | Per-client throttling with HTTP 429 on excess. Published ceilings could not be verified offline; treat any figure as indicative and back off exponentially on 429. |
| Objects | purchase requisitions (purchase requests), purchase orders, goods receipts, invoices, matching results, and master data (suppliers, cost centres, GL accounts, users, projects) |
## Publish target and field mapping
Each object below pairs the canonical intent fields with the destination's own fields and operations. The mapping is indicative until it is confirmed against a tenant at onboarding.
| Mapping | Detail |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Canonical to destination | service\_category, sow\.summary, supplier, cost\_center, amount, start\_date, end\_date, requester |
| Target | Purchase API: purchase order import (externally sourced order); purchase requisition create where the tenant's API version supports it |
| Requirement | Required |
| Notes | Header plus one or more service lines. Coding fields (supplier, cost centre, GL account) must resolve to values read from the Master Data API before publish. Whether requisitions can be created through the API, as opposed to read, is confirmed at onboarding |
| Mapping | Detail |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Canonical to destination | intent\_id -> externalCode |
| Target | externalCode on the Purchase API document header (purchase order; the requisition where API creation is enabled) |
| Requirement | Required |
| Notes | Stock client-supplied external reference: the key Basware uses to identify documents imported from an external system, unique per source and returned on read. Filtering reads by externalCode is indicative until confirmed at onboarding. UI deep link \{tenant\_host}/purchase/orders/\{external\_id} is illustrative |
| Mapping | Detail |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Canonical to destination | po\_number, status, supplier, amount, externalCode, matched\_invoice\_refs |
| Target | Purchase API: purchase orders (read); Invoice API and Matching API for invoices matched to the order |
| Requirement | Read scope only |
| Notes | Polled by externalCode. Confirm at onboarding whether an order raised from an API-created requisition inherits the requisition's externalCode; if not, composerID correlates through the requisition reference the order carries |
Basware enables APIs per customer tenant and issues the OAuth client for them, so expect an onboarding step with Basware before a first call, and confirm the tenant's environment host and P2P edition. Only the tenant can tell us which publish path exists: whether its Purchase API version accepts requisition creation or only externally sourced purchase order import, whether externalCode on that document is filterable on reads, and whether an order raised from a requisition inherits the code. If neither document exposes a writable externalCode in the tenant's version, composerID falls back to link mode and records the Basware document number against the Intent ID on its side. Master data (suppliers, cost centres, GL accounts, users) is tenant-specific and is read before publish, and the UI route in the deep link is illustrative until checked in the tenant.
## Next steps
The five ways composerID reaches a destination, and the minimum a destination must offer.
Plan, preflight and publish: how a decision becomes a valid record in a destination.
Every destination composerID documents, with its category and coverage status.