Version releases
We are constantly adding new features to Procountor API. This page has the planned changes in future releases as well as release notes for the current ones. For anyone interested, we recommend subscribing to our mailing list to get notifications about API changes as soon as they become available.
Currently available API versions
API Path | Version | Release Date | Support Ends |
---|---|---|---|
/latest |
Monthly release with no extended support. However, if new API version isn't released, it will continue to have the previous release | ||
/supported |
24.05 | Updated to the latest numbered version every three months | |
/v2405 |
24.05 | 2024-05-18 | mid-Feb 2025 |
/v2402 |
24.02 | 2024-02-17 | mid-Nov 2024 |
/v2311 |
23.11 | 2023-11-18 | mid-Aug 2024 |
You can find the version update schedule from Procountor news and announcements site.
Release notes
Changes highlighted in red are not backwards compatible
Planned changes ahead
- Payroll API: Our team is working on the Payroll API, which is scheduled for release by the end of Q1 2025.
- Introducing the Persons resource: In summer 2024, we’ll be rolling out the new Persons resource for adding, editing, and retrieving person information from the Person register. As part of this transition, support for Person from Business Partners will be deprecated. Stay tuned for further details!
Changes in version 24.07
Endpoints
- From this version onwards
GET /users/rights
endpoint will return a new schema aligned with Procountor UI (Management > Users and user rights) for therights
property. This change is applicable only to the latest API version. TheGET /users/rights/old
endpoint released in Procountor version 89 (June 2024) will continue to return the old schema until version 93 (October 2024). At this point, the endpoint will be removed.- Even though the endpoint will return a new schema, underlying rights will not change. For example, earlier if a user had no rights to accounting reports, this will remain the same also after the change.
- All the properties under
rights
that acceptString
will accept one of these enum valuesNO_ACCESS
,VIEWING_RIGHTS
,ALL_RIGHTS
,NOT_ENABLED
. Please noteNO_RIGHTS
has been replaced byNO_ACCESS
. - In the following table you can see how the fields in the new schema are mapped to the old one (currently returned by the
GET /users/rights/old
endpoint):
Fields in New Schema | Fields in Old Schema | Type of change |
---|---|---|
management |
management |
No change |
basicCompanyInfo |
basicCompanyInfo |
No change |
basicAccountingInfo |
basicAccountingInfo |
No change |
chartOfAccountsAndDefaultReports |
---didn't exist--- | New field |
usersAndUserRights |
companyUserManagement |
Renamed |
setUpACompany |
setUpACompany |
No change |
importData |
financialManagement/importData |
Moved from financialManagement
|
notifications |
financialManagement/notifications |
Moved from financialManagement
|
incomesRegisterCertificate |
financialManagement/incomesRegisterCertificate
|
Moved from financialManagement |
groupLetter |
sales/groupLetter |
Moved from sales |
auditLog |
---didn't exist--- | New field |
user |
---didn't exist--- | New |
editPersonalInfo |
management/editPersonalInfo |
Moved from management |
limitedDimensions |
limitations/limitedDimensions |
Moved from limitations |
blockSoloLoginToProcountor |
limitations/login |
Moved from limitations . Earlier called login |
sales |
sales |
No change |
salesOrGroupInvoices |
newSalesInvoice |
Renamed |
salesInvoiceSearch |
salesInvoiceSearch |
No change |
personalSalesInvoicesOnly |
limitations/personalSalesInvoicesOnly |
Moved from limitations |
customerRegister |
customerRegister |
No change |
productRegister |
productRegister |
No change |
purchases |
purchases |
No change |
purchaseInvoices |
newPurchaseInvoice |
Renamed |
purchaseInvoiceSearch |
searchInvoices |
Renamed |
personalPurchaseInvoicesOnly |
limitations/personalPurchaseInvoicesOnly |
Moved from limitations |
supplierRegister |
supplierRegister |
No change |
productRegister |
productRegister |
No change |
fixedAssetsRegister |
fixedAssetsRegister |
No change |
travelAndExpenses |
---didn't exist--- | New |
travelAndExpenseInvoices |
purchases/newTravelAndExpenseInvoice |
Moved from purchases . Earlier called newTravelAndExpenseInvoice |
travelAndExpenseInvoiceSearch |
purchases/searchInvoices |
Moved from purchases . Earlier called searchInvoices |
personalTravelAndExpenseInvoiceOnly |
limitations/personalTravelAndExpenseInvoiceOnly |
Moved from limitations |
invoiceCirculation |
---didn't exist--- | New |
verification |
purchases/verification |
Moved from purchases |
approval |
paymentTransactions/approval |
Moved from paymentTransactions |
personalApprovalsOrVerificationsOnly |
limitations/searchForPersonalApprovalsOnly |
Moved from limitations |
salaries |
salaries |
No change |
payroll |
payrollAccounting |
Renamed |
personalSalariesOnly |
limitations/personalSalariesOnly |
Moved from limitations |
personRegister |
personRegister |
No change |
workingTimeTracking |
workingTimeTracking |
No change |
personalWorkHourTrackingOnly |
limitations/personalWorkHourTrackingOnly |
Moved from limitations |
payments |
paymentTransactions |
Renamed |
payment |
payment |
No change |
salaryPayments |
salaryPayments |
No change |
markAsPaid |
markPaidElsewhere |
Renamed |
directBankTransfer |
directBankTransfer |
No change |
bankStatementAndReferencePayment |
bankStatementAndReferencePayment |
No change |
paymentAllocation |
paymentAllocation |
No change |
accounting |
---didn't exist--- | New |
journalReceipts |
purchases/newJournalReceipt |
Moved from purchases . Earlier called newJournalReceipt |
journalReceiptSearch |
purchases/searchInvoices |
Moved from purchases . Earlier called searchInvoices |
personalJournalReceiptsOnly |
limitations/personalJournalReceiptsOnly |
Moved from limitations |
closingOfAccountTools |
financialManagement/closingOfAccountsTool |
Moved from financialManagement |
preventCreatingEditingInvoices |
limitations/onlyAllowAccountingViewing |
Moved from limitations . Earlier called onlyAllowAccountingViewing |
accountingReports |
financialManagement/accountReporting |
Moved from financialManagement . Earlier called accountReporting |
archive |
financialManagement/archive |
Moved from financialManagement |
--doesn't exist--- | financialManagement |
Removed |
--doesn't exist--- | limitations |
Removed |
- In
GET /invoices
andGET /invoices/{invoiceId}
endpoints we have now added an optional fieldinvoiceSumInfo
to return invoice's total sum. This is supported for all receipt types exceptPERIODIC_TAX_RETURN
, which doesn't support invoice rows. To get additional information onexcludingVatTotal
andvatSumTotal
, please useGET /invoices/{invoiceId}
endpoint.
If the invoice has currency other than the one set for the environment (when fieldinAccountingCurrency
isfalse
), it returns sum in both the accounting and invoice currency.
Updated API reference documentation
- Documentation for
GET /invoices/personalapprovals
andGET /invoices/personalverifications
endpoints now correctly specifies that thetypes
field is required (nottype
), and that it accepts multiple receipt types separated by a comma. Available values fortypes
includePURCHASE_INVOICE
,TRAVEL_INVOICE
, andBILL_OF_CHARGES
. - Unnecessary mandatory fields
uriParams
and/oruriInfo
have been removed from several endpoints, which were added lately. NOTE only documentation was incorrect.GET /attachments
GET /payments/directsalarypayments
GET /bankaccounts
GET /products/{productId}
GET /bankstatements
GET /referencepayments
GET /currencies/exchangerate
GET /webhooks
GET /factoringcontracts
GET /products
GET /invoices
GET /products/groups
GET /ledgerreceipts
GET /payments/errormessages
GET /payments
- Some enum values were listed incorrectly lately – they either had Finnish translations or had duplicates or didn’t list the enum values. They have been corrected. NOTE only documentation was incorrect.
GET /products/{productId}
POST /products
PUT /products/{productId}
GET /company
GET /businesspartners/personaldetails
POST /payments/directbanktransfers
GET /payments
POST /payments
GET /payments/errormessages
GET /payments/{paymentId}
GET /users
- In Examples page, extra information has been added in Calculating invoice sum section
Changes in version 24.06
Endpoints
- From now on during error situations, following endpoints will no longer include the
model
field in their error responses. Instead, thefield
will provide the full JSON path to the invalid value.POST /payments
for invoice paymentPOST /payments/directsalarypayments
for direct salary paymentPOST /payments/directbanktransfers
for direct bank transfer
GET /users/rights/old
that will continue to return the old schema (similar to the current behavior of GET /users/rights
). This endpoint will be available for three months until Procountor release version 93 (October 2024). This grace period allows integrators to adapt their systems and migrate to the new schema that will be returned by GET /users/rights
in Procountor release version 90 (July 2024). Please check "Upcoming API breaking changes" section above.GET /users/rights/old
until it is removed in Procountor release version 93.Updated API reference documentation
- In API reference documentation
version
is no longer mentioned as required forPOST /invoices
endpoint. Please note thatversion
is still required forPUT /invoices/{invoiceId}
endpoint. - At the top of the API reference page, there is a new section on "Batch endpoints". This is only a reminder to the batch endpoints we already support.
- At the end of the API reference page, Schemas are now sorted in alphabetical order A -> Z.
Changes in version 24.05
Endpoints
base_url
anddocumentation
fields fromGET /status
have been removed from all API versions.- We have added a new field
procountorVersion
that returns Procountor version in use inGET /status
endpoint. e.g. "88.0.0". GET /invoices/{invoiceId}
,PUT /invoices/{invoiceId}
andPOST /invoices
endpoints now supportPURCHASE_ORDER
incounterparty.email
. Support has been added in all API versions.POST/reports/generalledger/{id}
now returns the proper response with defaultvatStatus
when VAT status is empty. It no longer returns the400
error.- Fixes to required user rights
- To fetch invoices waiting for personal approvals via
GET /invoices/personalapprovals
endpoint, logged in user must have "All rights" to Approval in “Invoice circulation” in Management > Users and user rights. If not, API sends empty list in response. - To fetch invoices waiting for personal verifications via
GET /invoices/personalverifications
endpoint, logged in user must have "All rights" to Verification in “Invoice circulation” in Management > Users and user rights. If not, API sends empty list in response. - Even if the "Prevent creating new invoices and editing invoices page" limitation is in use in Management > Users and user rights, it's now possible to
- Approve the invoice via
PUT /invoices/{invoiceId}/approve
, and - Mark invoice as paid via
PUT /invoices/{invoiceId}/paymentevents/markpaid
. - However, please note that adding or editing invoices is still not possible using the
POST /invoices
orPUT /invoices/{invoiceId}
endpoints, respectively.
- Approve the invoice via
- To fetch invoices waiting for personal approvals via
Updated API reference documentation
- We have updated our API reference documentation by replacing the references to EXPENSE_INVOICE with BILL_OF_CHARGES.
- In addition, the address field now correctly maps to the appropriate model and includes its own description in the following endpoints:
Endpoints | Description |
---|---|
GET /businesspartners/{id} |
|
In GET /businesspartners endpoint's response |
|
In GET /businesspartners​/personaldetails endpoint's response |
|
GET /invoices/{invoiceId} |
|
In POST /payments/directbanktransfers and POST /payments endpoints request body |
|
Changes in version 24.04
Endpoints
- We have added a new endpoint
GET /invoices/personalverifications
to fetch invoice ids waiting for verification from the currently logged in user, including those invoices where the user has been assigned as a substitute. Details of the returned invoice can be fetched fromGET /invoices/{invoiceId}
. This endpoint returns empty list- If the user doesn’t have any invoice to verify
- Invoice circulation is disabled for all the supported invoice types (
useForPurchaseInvoices
anduseForTravelAndExpenseInvoices
arefalse
inGET /company/invoicecirculation/settings
) - If the user doesn't have "All rights" to verify (
verification
inPurchasesRights
inGET users/rights
)
This endpoint supports required query parameter types
, which accepts more than one type, separated by comma. Available values are PURCHASE_INVOICE
,TRAVEL_INVOICE
, BILL_OF_CHARGES
. If the user doesn’t have required permission to the given invoice types
, 403
error is returned.
- We have also added a new endpoint
GET /invoices/personalapprovals
to fetch invoice ids waiting for approval from the currently logged in user, including those invoices where the user has been assigned as a substitute. Details of the returned invoice can be fetched fromGET /invoices/{invoiceId}
. This endpoint returns empty list- If the user doesn’t have any invoice to approve
- Invoice circulation is disabled for all the supported invoice types (
useForPurchaseInvoices
anduseForTravelAndExpenseInvoices
arefalse
inGET /company/invoicecirculation/settings
) - If the user doesn't have "All rights" to approve (
approval
inPaymentTransactionsRights
inGET users/rights
)
This endpoint supports required query parameter types
, which accepts more than one type, separated by comma. Available values are PURCHASE_INVOICE
,TRAVEL_INVOICE
, BILL_OF_CHARGES
. If the user doesn’t have required permission to the given invoice types
, 403
error is returned.
Others
- API reference documentation has been updated
- Endpoints that support batch requests, their ID parameter is now of
type
string
andformat
multi
- Endpoints that accept
integer
parameters,format
of those parameters have been changed fromint64
toint32
- Endpoints that support batch requests, their ID parameter is now of
This has been fixed for all API versions.
Changes in version 24.03
Endpoints
-
From now onwards following endpoints check whether usage settings (in Procountor UI: Management > Company info > Usage settings) to use cash discount is in use or not. If cash discount is not in use, API returns
400
error code when request is sent withcashDiscount
. This affects all API versions.POST /businesspartners
PUT /businesspartners/{id}
PATCH /businesspartners/{id}
-
GET/businesspartners/{id}
andGET/invoices/{id}
endpoints from now onwards do not returncashDiscount
inBusinessPartnerPaymentInfo
andPaymentInfo
object respectively, when there is no cash discount or cash discount is not in use (in Usage settings). This affects all API versions. -
In Swedish and Danish environments,
GET /ledgerreceipts
andGET /ledgerreceipts/{receiptId}
endpoints now return optionalserialNumber
, if it exists.SerialNumber
object consists ofseries
andnumber
.
Others
API Developers portal has been updated with own links for Sweden (e.g. Swedish Procountor API Terms of Use, General use and customer agreement terms, Partner program for Swedish software companies, Support and consultancy, Procountor customer service).
Changes in version 24.02
Endpoints
- To ensure that only the latest invoice is updated and there are no multiple accounting pages for the same invoice, it is now mandatory to send the latest invoice version in
version
when callingPUT /invoices/{invoiceId}
endpoint. UseGET /invoices
orGET /invoices/{invoiceId}
to obtain the latest invoice version. When trying to update invoice with an older invoice version, API now returns error code400
with proper error message. Note this change applies only to the latest API version.
No new API release in January, 2024
Changes in version 23.12
Endpoints
-
From
GET /businesspartners/personaldetails
endpoint, following fields inBusinessPartnerPaymentDetails
have been removed as they do not belong to a Person in Person register:cashDiscountDays
cashDiscountPercentage
-
Documentation for query parameter
originalInvoiceNumber
inGET /invoices
endpoint has been changed frominteger
tostring
in all API versions. Note, API request was already acceptingstring
.
-
POST /invoices
,PUT /invoices/{invoiceId}
andGET /invoices/{invoiceId}
endpoints now support 1 - 3 cash discount options inCashDiscountOption
. When sending more than 1 cash discount option inPOST /invoices
orPUT /invoices/{invoiceId}
endpoint:numberOfDays
anddiscountPercentage
must be unique- Smaller
numberOfDays
must have biggerdiscountPercentage
discountPercentage
must be less than 100
Otherwise in the above cases, API returns
400
error response.Provided cash discount options are saved in ascending order by
numberOfDays
. -
POST /businesspartners
,PUT /businesspartners/{id}
,PATCH /businesspartners/{id}
andGET /businesspartners/{id}
endpoints now support 1 - 3 cash discount options inCashDiscountOption
. When sending more than 1 cash discount option inPOST /businesspartners
,PUT /businesspartners/{id}
orPATCH /businesspartners/{id}
endpoint:numberOfDays
anddiscountPercentage
must be unique- Smaller
numberOfDays
must have biggerdiscountPercentage
discountPercentage
must be less than 100
Otherwise in the above cases, API returns
400
error response.Provided cash discount options are saved in ascending order by
numberOfDays
. -
GET /businesspartners/personaldetails
endpoint now returns currently logged in user's invoicing information from Person register in the newly added objectBasicInvoicingInfo
, which containscustomerNumber
,identifierType
andidentifier
. If the values for these fields are missing, emptyinvoicingInfo
is returned. -
From now on
PUT /invoices/{invoiceId}/verify
andPUT /invoices/{invoiceId}/approve
endpoints will validate VAT status / VAT% combination when verifying or approving invoices. If the invoice row has VAT% other than 0%, VAT status must be 'Domestic'. If this validation fails, API sends400
error and invoice status isn't changed.
Changes in version 23.11
Endpoints
-
Following new optional fields have been added to
cashDiscount
inpaymentInfo
used in Invoice endpoints:GET /invoices/{invoiceId}
,POST /invoices
,PUT /invoices/{invoiceId}
, and Business partners endpoints:GET /businesspartners/{id}
,POST /businesspartners
,PUT /businesspartners/{id}
,PATCH /businesspartners/{id}
optionList
that containsnumberOfDays
anddiscountPercentage
cashDiscountsTermType
that indicates the start point for payment due date calculation and can be eitherFROM_INV_DATE
orFROM_END_OF_MONTH
.FROM_INV_DATE
is default for all countries.FROM_END_OF_MONTH
can be used only in Denmark.Still maximum 1 cash discount option is supported. Any additional cash discount options sent in
POST /invoices
,PUT /invoices/{invoiceId}
,POST /businesspartners
,PUT /businesspartners/{id}
orPATCH /businesspartners/{id}
request will be ignored.
-
We have added a new validation rule when setting business partner group to inactive in
PUT /businesspartners/groups/{id}
. If a business partner group has been set as the Maksuvahti automated invoice sending exclusion group, that group cannot be set to inactive. If that is attempted,400
error response is returned with descriptive error message. You should remove the group from Maksuvahti's "Prevent automatic transferring" setting in Procountor UI Management > Company info > Debt collection settings, to be able to set the business partner group inactive again. GET /businesspartners/groups
now supports filtering bytype
. Supported types areCUSTOMER
,SUPPLIER
andPERSON
. For other type, API returns400
error response.
Older release notes
Older release notes can be found from their own page.