Basware

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

Basware Developer Portal

Basware API reference (Purchase, Invoice, Matching, Master Data)

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 (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.

Purchase document (services)

Publish the approved services or outsourced decision

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

Intent ID correlation

Carry the Intent ID

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

Purchase order and invoice read-back

Close the loop

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

How composerID connects

The five ways composerID reaches a destination, and the minimum a destination must offer.

Publishing

Plan, preflight and publish: how a decision becomes a valid record in a destination.

All destinations

Every destination composerID documents, with its category and coverage status.

⌘I

Get started

Concepts

Guides

Destinations

Upstream connectors

API reference

Endpoints

Manuscript API (Triage)

Manuscript endpoints

Resources

Integration path

Vendor documentation

Basware Developer Portal

Basware API reference (Purchase, Invoice, Matching, Master Data)

API posture

Publish target and field mapping

Next steps

How composerID connects

Publishing

All destinations

​Integration path

​Vendor documentation

Basware Developer Portal

Basware API reference (Purchase, Invoice, Matching, Master Data)

​API posture

​Publish target and field mapping

​Next steps

How composerID connects

Publishing

All destinations

Integration path

Vendor documentation

API posture

Publish target and field mapping

Next steps