Release Notes

Information about future and past API releases

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.

Subscribe to our mailing list

Currently available API versions

Procountor API version diagram

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

Reminder: Do not request a new access token for every API call

  • Remember that API access tokens are valid for one hour (3600 seconds) from the time of issuance. Rather than requesting a new access token for every API call, please reuse the existing token until it expires.

Upcoming API breaking changes

GET /users/rights will start to return new schema for rights property

  • In the upcoming Procountor release version 90 (scheduled for July 2024), the GET /users/rights endpoint will return a new schema aligned with Procountor UI (Management > Users and user rights) for the rights property. This change is applicable only to the latest API version.
    • Even though the endpoint will start to 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 accept String will accept one of these enum values NO_ACCESS, VIEWING_RIGHTS, ALL_RIGHTS, NOT_ENABLED. Please note NO_RIGHTS has been changed to NO_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 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

Other 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.06

Endpoints

  • From now on during error situations, following endpoints will no longer include the model field in their error responses. Instead, the field will provide the full JSON path to the invalid value.
    • POST /payments for invoice payment
    • POST /payments/directsalarypayments for direct salary payment
    • POST /payments/directbanktransfers for direct bank transfer
  • We have added a new endpoint 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.
  • If you do not have time to adjust to the breaking change that will be releaed in July, you can use this new endpoint 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 for POST /invoices endpoint. Please note that version is still required for PUT /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 and documentationfields from GET /status have been removed from all API versions.
    • We have added a new field procountorVersion that returns Procountor version in use in GET /status endpoint. e.g. "88.0.0".
    • GET /invoices/{invoiceId}, PUT /invoices/{invoiceId} and POST /invoices endpoints now support PURCHASE_ORDER in counterparty.email . Support has been added in all API versions.
    • POST/reports/generalledger/{id} now returns the proper response with default vatStatus when VAT status is empty. It no longer returns the 400 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 or PUT /invoices/{invoiceId} endpoints, respectively.

    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}
    PUT /businesspartners/{id}
    PATCH /businesspartners/{id}
    POST /businesspartners
    • addressis mapped to BusinessPartnerAddress instead of Address
    • billingAddress is mapped to BusinessPartnerBillingAddress instead of Address
    • deliveryAddress is mapped to BusinessPartnerDeliveryAddress instead of Address
    In GET /businesspartners endpoint's response
    • billingAddress is mapped to BusinessPartnerBillingAddress instead of Address
    In GET /businesspartners​/personaldetails endpoint's response
    • address is mapped to PersonAddress instead of Address
    GET /invoices/{invoiceId}
    PUT /invoices/{invoiceId}
    POST /invoices
    • billingAddress is mapped to BusinessPartnerBillingAddress instead of Address
    • deliveryAddress is mapped to BusinessPartnerDeliveryAddress instead of Address
    • `counterParty.counterPartyAddress` is mapped to InvoiceCounterpartyAddress instead of Address
    In POST /payments/directbanktransfers
    and POST /payments endpoints request body
    • recipientNameAndAddress is mapped to PaymentRecipientNameAndAddress instead of Address
    • receiverBankNameAndAddress is mapped to PaymentReceiverBankNameAndAddress instead of Address
    • intermediaryBankNameAndAddress is mapped to PaymentIntermediaryBankNameAndAddressDTO instead of Address

    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 from GET /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 and useForTravelAndExpenseInvoices are false in GET /company/invoicecirculation/settings)
      • If the user doesn't have "All rights" to verify (verification in PurchasesRights in GET 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 from GET /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 and useForTravelAndExpenseInvoices are false in GET /company/invoicecirculation/settings)
      • If the user doesn't have "All rights" to approve (approval in PaymentTransactionsRights in GET 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 and format multi
      • Endpoints that accept integer parameters, format of those parameters have been changed from int64 to int32

    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 with cashDiscount. This affects all API versions.

      • POST /businesspartners
      • PUT /businesspartners/{id}
      • PATCH /businesspartners/{id}
    • GET/businesspartners/{id} and GET/invoices/{id} endpoints from now onwards do not return cashDiscount in BusinessPartnerPaymentInfo and PaymentInfo 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 and GET /ledgerreceipts/{receiptId} endpoints now return optional serialNumber, if it exists. SerialNumber object consists of series and number.

    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 calling PUT /invoices/{invoiceId} endpoint. Use GET /invoices or GET /invoices/{invoiceId} to obtain the latest invoice version. When trying to update invoice with an older invoice version, API now returns error code 400 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 in BusinessPartnerPaymentDetails have been removed as they do not belong to a Person in Person register:

      • cashDiscountDays
      • cashDiscountPercentage

    • Documentation for query parameter originalInvoiceNumber in GET /invoices endpoint has been changed from integer to string in all API versions. Note, API request was already accepting string.

    • POST /invoices, PUT /invoices/{invoiceId} and GET /invoices/{invoiceId} endpoints now support 1 - 3 cash discount options in CashDiscountOption. When sending more than 1 cash discount option in POST /invoices or PUT /invoices/{invoiceId} endpoint:

      • numberOfDays and discountPercentage must be unique
      • Smaller numberOfDays must have bigger discountPercentage
      • 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} and GET /businesspartners/{id} endpoints now support 1 - 3 cash discount options in CashDiscountOption. When sending more than 1 cash discount option in POST /businesspartners, PUT /businesspartners/{id} or PATCH /businesspartners/{id} endpoint:

      • numberOfDays and discountPercentage must be unique
      • Smaller numberOfDays must have bigger discountPercentage
      • 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 object BasicInvoicingInfo, which contains customerNumber, identifierType and identifier. If the values for these fields are missing, empty invoicingInfo is returned.

    • From now on PUT /invoices/{invoiceId}/verify and PUT /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 sends 400 error and invoice status isn't changed.

    Changes in version 23.11

    Endpoints

    • Following new optional fields have been added to cashDiscount in paymentInfo 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 contains numberOfDays and discountPercentage
      • cashDiscountsTermType that indicates the start point for payment due date calculation and can be either FROM_INV_DATE or FROM_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} or PATCH /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 by type. Supported types are CUSTOMER, SUPPLIER and PERSON. For other type, API returns 400 error response.

    Changes in version 23.10

    Endpoints

    • In Swedish and Danish environments, receipts are now automatically assigned a new serial number when financial year is closed. This is to ensure an unbroken receipt series and prevent invalidation after year is closed.

      • Purchase invoice, sales invoice, expense claim, travel invoice and journal with a serial number can not be invalidated anymore with PUT /invoices/{invoiceId}/invalidate request. Otherwise, 400 error response is returned.
      • Journal with a serial number can not be invalidated anymore with PUT /ledgerreceipts/{receiptId}/invalidate request. Otherwise, 400 error response is returned.
      • Journal with a serial number can not change its status to Unfinished through PUT /ledgerreceipts/{receiptId}/unfinished request. Otherwise, 400 error response is returned.

    • We have added a new optional field receiptNumber that returns number of the ledger receipt in GET /ledgerreceipts endpoint.

    • From now on, API sends 403 error response when trying to delete payment event in MARKED_PAID status that was created by credit invoice allocation via DELETE /invoices/{invoiceId}/paymentevents/{paymentEventId} endpoint.
    • Bug in PUT /invoices/{invoiceId}/sendToCirculation that sent INVALID_BIC error when trying to approve Swedish purchase e-invoice, where the payment method was Bankgiro or Plusgiro has been fixed.

    Others

    • Link to Privacy policy has been added to API login page. This has been implemented for all API versions.
    • Earlier in API login page, when trying to navigate back from “Company select” view, previous API UI login page was not displayed. This has now been fixed.
    • Examples of curl request for sending sensitive information has been added to API authentication and M2M authentication pages in API documentation.

    Changes in version 23.09

    Endpoints

    • To increase security, from now onwards request sent with URL parameters during API and M2M authentication in the following endpoints will receive HTTP 403 error code. This affects all API versions. But if you are already sending request parameters in body and not as params in URL - no change is required on your side.

      • /api/oauth/token
      • /api/oauth/key

    • We have added a new endpoint GET /invoice/{invoiceId}/image to fetch invoice image as PNG, one page at a time.

    • GET /products endpoint now supports filtering by product name, including part of product name.
    • In GET /businesspartners endpoint, it is now possible to filter business partners by part of partner name. Earlier, name header parameter supported only full match.

    Older release notes

    Older release notes can be found from their own page.

    Old release notes