Get answers to Frequently Asked Questions

ExternalCodes for records in Basware API need to meet the following criteria:

  1. They must retain their value when updating records (else data updates will not work)
  2. They most not exceed the field max length (else the record will be rejected by Basware API).

Two common ways are 1) using UUIDs and 2) Concatenating the externalCode from other key values, such as SourceSystem_CompanyCode_PONumber_PORowNumber_GRNumber.

The UUIDmethod requires saving this guid to the sending system.  The second "composite key" method may make integration debugging more straightforward and requires making sure the combined key does not exceed the max length for externalCode -field.

It's up to the customer implementation what is the best way to create them.

Please refer to the error handling section of Purchase-to-Pay API manual.

Please check the errorFeedbacks API. Note that specific kinds of errors can take some minutes to become available in errorFeedbacks API due to internal retry logic. Try to use GET errorFeedbacks with just daterange search, setting the date to one day before your expected error (in case of timezone differences). If this does not resolve your issue, please contact Basware support.

There is a setting in P2P admin, settings section called "Delete existing user groups when importing users". This setting needs to be enabled in order to clear existing user groups during import.

No, each bank account on the vendor needs to be unique.

This typically happens for invoices which have already been acknowledged. API allows acknowledging an invoice only once (unless it is retransferred from P2P). Already acknowledged invoices have 'processingStatus' = 'TransferInProgress'.

Please check that you are sending the x-amz-meta-continuationtoken parameter as a request header parameter. It does not work if it is not sent in header (for example in body).

The x-amz-meta-continuationtoken parameter is preconfigured in our Postman templates. Please try it out through postman using the preconfigured template, that should help spot the difference between how it is set up in the request sent by Postman and sending it in your HTTPS request.

There is filtering in use for records which are sent unchanged from the last time the record was sent to API. Such records are not forwarded from API to the target systems. Please make a small change to the record manually (such as update the name) and resend, then it will pass the check in API. Alternatively, you can delete the record(s) from API and then post again.

The swagger definition should serve you the same way as WSDL. You can download the swagger here  and then validate the messages against that. However, there is no json schema or WSDL file currently available.

There is no way at the moment to keep changes made manually to records which are updated through the API. An exception to this is the vendors -interface, where some of the interface fields can be configured so API data does not overwrite existing data in P2p. This functionality to vendors -interface is planned to be released in Q3/2020.

Please find a way to update the data fully in your source system, alternatively you could consider creating a separate maintenance table for particular items - please discuss options for you specific scenario with your Basware consultant.

The vendor's default currency is taken from field 'currencyCode' under paymentMeans block. Please make sure default = 'true' on the paymentMeans block with the default currency.
The delete command deletes data from API only, you'll need to manually delete the data from the target system(s). The delete functionality is implemented mainly for manual clean-ups during / after development and does not support deleting the data all the way in target systems. Note in some cases the target systems also have restrictions on deleting the data if there are dependencies to it in other records in the system.
The order header sums are not imported through API. MatchingOrder APIs were built mainly for the new html5 based P2P user interface (Edge), which takes sums from order lines. In silverlight based UI (Workplace) the order sums are not available for API-imported orders. Matching is fully possible using both user interfaces for orders imported through API.

Yes you can. There are some things which need to be taken into account. The most important thing is to update user externalCodes in P2P to have same externalCode values that will be sent for each user through users API. This will enable users API to correcly identify existing users for update instead of creating new users instead. It is important to update existing users instead of creating new ones so the users preserve access to invoices they have processed and invoices they currently have in circulation.

User externalCodes can be updated either manually through the user administration -module in P2P or automatically with more direct access to the system. Basware consultants and delivery partners can update the externalCodes directly in P2P. Note that when importing users through API, the user will be available for a GET operation in users API only after the user has been POSTed to users API.

Please test this procedure in test environment to verify all the details are correctly in place before applying the same in a production environment.