Release Notes

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

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

• These 2 SIE file endpoints will be renamed in the upcoming version 100.0 in April:
  • from GET /SIE/availability to GET /sie/availability
  • from GET /SIE/file to GET /sie/file

In the future, we will deprecate Persons from Business Partners. This change will be communicated later.

Changes in version 25.03

Endpoints

Breaking changes

• Support for salary category EMPLOYER_PAYMENTS has been removed from GET /payrolls/salarytypes endpoint.
• GET /invoices/{invoiceId}/comments/taggableusers endpoint now checks if the user has rights to the given invoice AND if the invoice specific discussion setting is enabled or not (allowInvoiceSpecificDiscussion in GET /company/invoicecirculation/settings endpoint). If the validation fails, endpoint returns 403 error code instead of 200 successful response.

Introducing A New, Easier Integration Activation Process

• We are excited to announce the release of our new API activation process, designed to streamline and enhance the integration experience for both integrators and the integration users.
• For integrators, this new process offers a seamless way to create, manage, and share integration specifications. You can efficiently enroll new customers into your integrations and handle change management with ease.
• For customers, the new activation process is a game-changer. Integrations can now be activated through a simple self-service flow. By clicking on an “activation link”, specific to each integration, customers are guided through an automated activation process that requires no technical knowledge.
• At the end of a successful integration activation flow:
• A technical user, defined by the integrator in the integration specification, is added to the customer environment(s) with the user role of "API technical user"
• The API key is created for this technical user and shared with the integrator
• User rights for this technical user are set as defined in the integration specification in customer's environment(s)
• "Allow the usage of invoiceable API clients" setting is enabled in customer's environment(s) in Management > Company info > Usage settings
• A confirmation email is sent to the user who initiated the integration activation(s)
• This new activation process will replace the current manual method of setting up integrations, becoming the default method moving forward. Please note that this process is supported only for M2M authentication.
• Additionally, existing integrations can be transitioned to this new process. To start with the migration, please submit this form.
• For more information and detailed instructions please check
  • Creating an integration specification - for integrators
  • Activating Integrations in Procountor - for customers

New Integrations endpoints in Version 25.03

• The following new endpoints are related to the new integration activation flow mentioned above.
• GET /integrations/{requestId}
  • Returns information on companies looking to activate the integration for the specified requestId, which is appended in the "Integration callback URL" during the new integration activation flow.
  • User sending the request must belong to the company that contains API Integrator tool.
  • requestId must be valid. If it has expired, 410 error is returned.
  • It's possible to activate integration for multiple companies using the same requestId.
  • Information returned in extraInfo depends on the fields marked as required for user consent in the integration specification.
• PUT /integrations/{requestId}
  • To approve and/or reject integration activation request.
  • User sending the request must belong to the company that contains the API Integrator tool.
  • Request parameter requestId must be valid. If it has expired, 410 error is returned.
  • The number of companyId in request body in approve and reject combined must match the number of companyId returned in GET /integrations/{requestId} response in companiesToIntegrate. Otherwise, 400 is returned.
  • If the request is successful, a technical user with the "API technical user" role is added to all the approved companies, and an API key for the technical user is generated and returned. If the technical user already belongs to the approved environment (e.g. it has been added manually), its existing API key is returned.

New Payroll Endpoints in Version 25.03

• As part of the Payroll API, we are introducing new endpoints for employees’ salary base:
• GET /payrolls/employees/{id}/salarybase
  • Endpoint for fetching the salary base of the specified employee.
  • Salary base should always have at least one salary row in rows. Some base rows are created automatically and others can be added. Each salary base row consists of id, salaryTypeCode, customName, quantity,unitValue,paymentPercent,recoveryDetails,carBenefitDetails,baseSalaryRow.
  • Apart from the salary base row, it also returns id, employeeId, notes, version.
• PUT /payrolls/employees/{id}/salarybase
  • Endpoint for updating the salary base for the specified employee.
  • notes and salary base row information can be updated.

Changes to other endpoints in version 25.03

• If the due date of the e-invoice is in the past or the current day, API returns error code 400 in these endpoints: POST /invoices, PUT /invoices/{invoiceId}, PUT /invoices/{invoiceId}/send
• In the following endpoints, if the electronic invoice operator ID is same as electronic invoice address or EDI ID, API returns 400, unless they are same in Tieke register. In the latter case, error code isn't returned.
  • POST /invoices
  • PUT /invoices/{invoiceId}
  • POST /businesspartners
  • PUT /businesspartners/{id}
  • PATCH /businesspartners/{id}

Changes in version 25.02

Endpoints

Breaking changes

• preventPayeeInformationChange field has been removed from GET /company/invoicecirculation/settings endpoint as this setting is no longer supported in UI.

Changes to other endpoints

• Bug fix: During high load, trying to fetch a specific sales or purchase invoice by calling GET /invoices/{invoiceId} resulted in UNABLE_TO_GET_CONNECTION error. This has been fixed now.
• We have made performance improvements to GET /invoices endpoint endpoint. You can now expect faster response times.

Changes in version 25.01

Endpoints

Breaking changes

• Since EDI (OVT) identifier is supported only in Finnish environments, from now on POST /invoices will return error OVT_NOT_ALLOWED instead of INVALID_OVT when counterparty.einvoiceAddress.ediId is sent for environments other than Finnish.

New Payroll endpoints

• As part of the Payroll API we are introducing new delete endpoints for employee’s employment details in salary info:
  • DELETE /payrolls/employees/{id}/salaryinfo/employments/{employmentId}
    • Deletes employee’s employment.
    • Salary base is automatically recreated after deletion.
    • To delete employment, full payroll user rights is required and employment id must be valid.
    • Employment must belong to employee with employee id id.
  • DELETE /payrolls/employees/{id}/salaryinfo/taxCards/{taxCardId}
    • Deletes employee’s tax card.
    • Salary base is automatically recreated after deletion.
    • To delete taxcard, full payroll user rights is required and tax card id must be valid.
    • Tax card must belong to employee with employee id id.
  • DELETE /payrolls/employees/{id}/salaryinfo/laborUnionMemberships/{laborUnionMembershipId}
    • Deletes employee’s labor union membership.
    • Salary base is automatically recreated after deletion.
    • To delete labor union membership, full payroll user rights is required and labor union membership id must be valid.
    • Labor union membership must belong to employee with employee id id.

Changes to other endpoints

• Bug fix: When the email communications setting - “Notifications if I have been mentioned in a discussion” was enabled in Procountor UI Basics > Personal info and settings, API returned 400 when attempting to tag a user in a comment via POST /invoices/{invoiceId}/comments endpoint in invoices that didn’t have ledger receipt. This has now been fixed.

Changes in version 24.12

Endpoints

Breaking changes

• When fetching dimensions, if user doesn't have viewing or all rights to "Basic accounting info", GET /dimensions endpoint returns 403 error code instead of 200.
• When fetching details of a specific dimension, if user doesn't have viewing or all rights to "Basic accounting info", GET /dimensions/{dimensionId} endpoint returns 403 error code instead of 200.

New Payroll endpoints

• As a part of the Payroll API, we are introducing following new endpoints for employee's employment details in salary info:
  • GET /payrolls/employees/{id}/salaryinfo and PUT /payrolls/employees/{id}/salaryinfo
    • Endpoints for fetching and updating the salary info for the specified employee.
    • GET returns and PUT updates the salary info data under incomeConfiguration, insurancesConfiguration and internationalSituationsConfiguration.
    • Employment, tax card and labor union have their own endpoints.
    • PUT automatically updates the salary base for the employee based on salary info data.
  • POST /payrolls/employees/salaryinfo
    • Creates a new employee salary info and returns it.
    • Also creates automatically salary base for employee based on salary info data under incomeConfiguration, insurancesConfiguration and internationalSituationsConfiguration.
    • To be able to create a new employee with POST /payrolls/employees/salaryinfo, first create person with POST /persons.
  • GET /payrolls/employees/{id}/salaryinfo/employments and POST /payrolls/employees/{id}/salaryinfo/employments
    • Endpoints for fetching and creating employment details for the specified employee.
    • POST creates and GET returns the following employment data: id, keva, startDate, endDate, type, terminationReason, registrationGroundId and version.
  • GET /payrolls/employees/{id}/salaryinfo/employments/{employmentId} and PUT /payrolls/employees/{id}/salaryinfo/employments/{employmentId}
    • Endpoints for fetching and updating the specified employment details for the specified employee.
    • GET returns and PUT updates the following employment data: id, keva, startDate, endDate, type, terminationReason, registrationGroundId and version.
  • GET /payrolls/employees/{id}/salaryinfo/taxcards and POST /payrolls/employees/{id}/salaryinfo/taxcards
    • Endpoints for fetching and creating the tax card details for the specified employee.
    • POST creates and GET returns the following tax card data: id, type, revised, validFrom, basePercent additionalPercent, annualIncomeLimit, limitUsed, comments, created and version.
    • Only ONE_INCOME_LIMIT and TAX_AT_SOURCE types are supported.
    • POST automatically recreates salary base for the employee.
  • GET /payrolls/employees/{id}/salaryinfo/taxcards/{taxCardId} and PUT /payrolls/employees/{id}/salaryinfo/taxcards/{taxCardId}
    • Endpoints for fetching and updating the specified tax card details for the specified employee.
    • GET returns and PUT updates the following tax card data: id, type, revised, validFrom, basePercent additionalPercent, annualIncomeLimit, limitUsed, comments, created and version.
    • Only ONE_INCOME_LIMIT and TAX_AT_SOURCE types are supported.
    • PUT automatically recreates salary base for the employee.
  • GET /payrolls/employees/{id}/salaryinfo/laborunionmemberships and POST /payrolls/employees/{id}/salaryinfo/laborunionmemberships
    • Endpoints for fetching and creating the labor union details for the specified employee.
    • GET returns and POST creates following the labor union data: id, laborUnionSettingId, department, membershipId membershipStart, membershipEnd, explanation and version.
  • GET /payrolls/employees/{id}/salaryinfo/laborunionmemberships/{laborUnionMembershipId} and PUT /payrolls/employees/{id}/salaryinfo/laborunionmemberships/{laborUnionMembershipId}
    • Endpoints for fetching and updating the specified labor union details for the specified employee.
    • GET returns and PUT updates the following labor union data: id, laborUnionSettingId, department, membershipId membershipStart, membershipEnd, explanation and version.

Changes to other endpoints

• Bug fix: When payment based accounting is used and vatStatus wasn't provided during the invoice creation, GET /invoices/{invoiceId} endpoint will now return vatStatus from the ledger receipt. Earlier in such case vatStatus was returned.
• In POST /businesspartners, GET /businesspartners/{id} and PUT /businesspartners/{id} endpoints, we have added these new optional fields under invoicingInfo: buyerReferenceIdentifier, sellerReferenceIdentifier, orderReference, orderNumber, agreementNumber, accountingCode, deliverySite, tenderReference. These fields are supported only in Finnish environments.

Changes in version 24.11

Endpoints

Breaking changes

• PUT /dimensions has been removed. Please use PUT /dimensions/{dimensionId} instead, as communicated earlier.

• When fetching attachments, GET /attachments endpoint returns 403 error instead of 200 OK response with empty list, in the following situations:

  • When special right is missing
  • There is no attachment to return because of insufficient user right
  • User doesn't have the necessary right to any of the types given in the request parameter

• To fetch list of supported delivery terms, GET /company/deliveryterms endpoint requires all rights to sales or purchase invoices. If the required right is missing, endpoint returns 403 error instead of 200 OK response.

• When fetching sales or purchase products, if the required rights are missing, GET /products endpoint returns 403 error instead of 200 OK response with empty list. Note, to fetch travel products, type parameter must be given and it doesn't require user rights.

** New SIE endpoints**

• Following new SIE endpoints are supported only in Swedish environments:
  • GET /SIE/availability
    • New endpoint that returns possible date options (lastValidEndDate and list of accounting period start dates in accountingPeriodStart) for exporting a SIE-file through the API.
  • GET /SIE/file
    • The endpoint requires two parameters: accountingPeriodStart and exportEndDate. The accountingPeriodStart defines the starting point for comparison years (RAR -1 and RAR -2 etc.) and needs to match the start date of the existing financial years. The exportEndDate determines the end of export time period and all transactions for that financial year are included in the file.

** New Payroll endpoints**

• As a part of the Payroll API, we are introducing a new endpoint for salary types.
  • GET /payrolls/salarytypes
    • Returns the list of salary types with basic information: name, code, category, unit, unitValue, paymentPercent, affectsHealthInsurance, affectsPensionInsurance affectsUnemploymentInsurance, affectsAccidentAndGroupLifeInsurance, incomeType and incomeTypeCode.
    • It is possible to filter salary types by the following parameters: name, code category incomeType and incomeTypeCode.
    • Pagination and sorting by salary type code are supported.
    • Partial search is supported for name and incomeType.
    • Endpoint also returns translations for the salary type name.

** Other endpoints**

• If Ropo Capital has been selected as the debt collection partner, then collectionPartner in GET /company/expenses/collectionpenal/settings endpoint returns "ROPO" instead of "TRUST".
• If Kravia has been selected as the debt collection partner, then collectionPartner in GET /company/expenses/collectionpenal/settings endpoint returns "KRAVIA" in both Finnish and Swedish environments.

Changes in version 24.10

Endpoints

Breaking changes

• The temporary GET /users/rights/old endpoint, which was created to give extra time to adjust to the changes made in GET /users/rights that returned new schema for rights, will be removed as previously communicated. To see how the fields in the new schema map to the old ones, please refer to Release notes from API version 24.07
• For security reasons, GET /webhooks endpoint will no longer return sharedSecret in authenticationMeta when HMAC authentication type is used.
• In GET /ledgerreceipts, when filtering ledger receipts by types BANK_STATEMENT_AS_RECEIPT or REFERENCE_PAYMENT, endpoint will now return 403 error instead of 200, if the user right to Payments > Bank statements and reference payments is missing.
• In GET /ledgerreceipts/{receiptId}, when fetching specific ledger receipt where receiptId is either BANK_STATEMENT_AS_RECEIPT or REFERENCE_PAYMENT, endpoint will now return 403 error instead of 200, if the user right to Payments > Bank statements and reference payments is missing.
• Since Procountor is exiting Denmark in the end of 2024, Danish Sales invoices cannot be set as to be Sent from the PUT /invoices/{invoiceId}/send endpoint anymore, if the invoice date is after 31.12.2024. API will return 400 error instead.

New Payroll endpoints

• As a part of the Payroll API, we are introducing new endpoints related to employees in the Employee register, salaries basic information and labor union settings.
  • GET /payrolls/employees
    • New endpoint to fetch the list of employees with basic information: id, lastName, firstName, ssn, employeeAddress, salaryChannel, automatedTaxCard and information if the employee is active.
    • It is possible to filter employees by the following query parameters:
      • name, ssn - supported in header
      • personNumber, personGroupId, includeInactive and salaryChannel - supported in url
    • Partial search is supported for name, ssn and personNumber.
    • Pagination and sorting by id are also supported.
  • GET /payrolls/salariesbasicinfo
    • New endpoint to fetch salaries basic information: yearlyFigures, workHours, incomesRegisterConfiguration, pensionContracts, accidentInsurancePolicies.
  • GET /payrolls/laborunionsettings
    • New endpoint to fetch the list of labor union settings with id and name.

Automatic handling of collection fees and penal expenses

• In this version we have added support for automatic handling of collection fees and penal expenses on sales invoice. For these following endpoints have been modified. As this feature is already supported in Procountor UI, for more information please check Procountor manual.
  • PUT /invoices/{invoiceId}/paymentevents/markpaid
    • It now supports request parameter addPenalExpense. When marking the overdue sales invoice as paid, if you want to automatically include a penal expense in the business partner's next sales invoice, then call the endpoint with addPenalExpense=true. Default is false, so penal expense is not added automatically.
    • Automatic handling of collection and penal costs setting must be enabled prior to this. This setting can be checked from GET /company/expenses/collectionpenal/settings. In Procountor UI, it is found under Management > Company info > Debt collection settings.
  • DELETE /invoices/{invoiceId}/paymentevents/{paymentEvent}
    • This endpoint will also remove uncollected penal expenses when removing overdue sales invoice's payment transaction, which was earlier marked as paid. The deletion of uncollected penal expenses will only occur after the user approves the action via 2-factor authentication.
  • POST /invoices
    • It now supports request parameter addCollectionPenalCosts when creating a new sales invoice to a business partner. Use addCollectionPenalCosts=true if you want to automatically add collection fees and penal expenses to the new sales invoice for the business partner who had paid the invoice late and to whom the payment reminders were sent. Default is false, so these costs aren't added automatically.
    • Note, if the invoice was paid late but payment reminders weren't sent to the business partner -> only penal expense will be added, or if the invoice wasn't paid late but payment reminders were sent -> only collection fee will be added.
    • These fees are added only if
      • Automatic handling of collection and penal costs setting is enabled
      • For adding collection fees, collection costs product is defined
      • And for adding penal expenses, penal expense product is defined
    • These settings can be checked from GET /company/expenses/collectionpenal/settings. In Procountor UI it is found under Management > Company info > Debt collection settings.

Other endpoints

• In POST /businesspartners, GET /businesspartners/{id}, PUT /businesspartners/{id}, PATCH /businesspartners/{id} endpoints, there is now a new field called denyEInvoiceReminders in the paymentInfo value. This value doesn't affect anything yet, but it will deny the sending of payment reminders to the given business partner as e-invoice or email in Finland, if a related setting from the Debt collection settings on the Procountor UI is on. The Debt collection setting on the Procountor UI will be released later, and the new field will start affecting from that point onwards.
• We are introducing a new endpoint, GET /company/einvoiceaddresses, to fetch company's electronic invoice addresses. These addresses can be found in Procountor UI under Management > Company info > E-invoice and Scanning addresses.
• Bug fix: When ledger receipt is updated via PUT /ledgerreceipts/{receiptId}, invoice version will no longer be updated. This occurred previously, when the ledger receipt was updated for the first time.
• Bug fix: In POST /invoices and PUT /invoices/{invoiceId} endpoints, counterpart.contactPersonName will again accept maximum 70 characters instead of 28.

Updated API Developers Portal

• Under Getting started, you can find carousel of reference companies that already use Procountor.

Changes in version 24.09

Endpoints

• As part of the Payroll API we are introducing new endpoints regarding Person’s default dimensions:
  • GET /persons/{id}/defaults/dimensions
    • Fetches the basic information on default dimensions and their items for a particular person.
  • GET /persons/{id}/defaults/dimensions/{dimensionId}
    • Fetches the detailed information on default dimensions items for a particular person.
  • PUT /persons/{id}/defaults/dimensions/{dimensionId}
    • Updates the dimension items percents for a particular person. The number of items in a dimension is unlimited but the total percent must equal to 100.Since only percent can be updated, new endpoint GET /persons/{id}/defaults/dimensions/{dimensionId} can be called first to fetch the item's other details.
  • GET /persons/{id}/defaults/products
    • Fetches the default products for a particular person.
• In POST /payments endpoint a new restriction has been added for Danish environments: payments cannot be made after 31.12.2024. If the payment date is on 1.1.2025 or later, status code 400 is returned with the error PAYMENT_DATE_IS_AFTER_ENDING_SUPPORT_FOR_DANISH_ENVIRONMENTS
• In GET /invoices/{invoiceId}/comments endpoint inactive users are no longer listed as tagged users under taggedUsersInfo.
• PUT /invoices/{invoiceId}/comments/{commentId}/{userTagId}/read endpoint has been renamed to PUT /invoices/{invoiceId}/comments/{commentId}/read so that user who is tagged multiple times in the same comment can mark the comment as read in the single request. Additionally, from now on only the tagged user is able to mark the comment as read. Otherwise, API sends 400 error.
• In GET /dimensions endpoint dimensions can now be filtered by name and codeName. Also partial search is supported. Filtering result is returned in an array.
• In GET /invoices/{invoiceId} endpoint invoice row with null quantity is no longer returned in invoiceRows.

Changes in version 24.08

Endpoints

Endpoints for new resource Persons

• We are introducing new endpoints for Persons resource for adding, editing and fetching person information from the Person register. In the future, we will be deprecating Persons from the Business Partners. This will be informed later well ahead of the change.
• Person's id is same as business partner's partnerId for type PERSON.
• New endpoints for Person:
  • GET /persons
    • Returns the list of persons with basic information: id, lastName, firstName, jobTitle, deliveryAddress, invoicingInfo, registryInfo.
    • It is possible to filter persons by the following parameters:
      • name and identifier in header.
      • personNumber, mainPersonGroup, personGroupId and includeInactive in url.
    • Also pagination and sorting by id are supported.
    • Partial search is supported for name, identifier and personNumber.
  • GET /persons/{id}
    • Returns person's detailed information.
    • To get more information on Person group, please use GET /businesspartners/groups/{id}.
  • POST /persons
    • New endpoint to add a new person to the Person register.
    • Note in Swedish environments, personNumber is required.
  • PUT /persons/{id}
    • New endpoint to modify details of an existing person in the Person register.
    • Note if the person is already in Employee register,
      • identifier and identifierType can't be updated
      • if salary channel is e-salary, accountNumber must support e-salary
      • accountNumber can be changed but it can't be removed
      • Otherwise, in the above 3 cases, API sends 400 error

Endpoints related to invoice comments

• We have added a new endpoint GET /invoices/{invoiceId}/comments/{commentId} to get more detailed information about the tagged users in the comment.
  • In case a comment does not contain any tagged user, the response will not include the taggedUsers array.
  • The read property within the taggedUsers array indicates the timestamp when the comment was read.
  • If a tagged user has not read the comment, the read property will not be included in the response for that user.
• We have added a new endpoint PUT /invoices/{invoiceId}/comments/{commentId}/{userTagId}/read to indicate that the tagged user has read the specified comment.
  If the comment has been marked as read for the tagged user already, API sends 400 error response when the same request is sent next time.
• We have added taggedUsersInfo optional object in existing endpoint GET /invoices/{invoiceId}/comments to fetch information about the tagged users.
  • taggedUsersInfo contains numTaggedUsers and readByAllTaggedUsers fields.
  • taggedUsersInfo is returned only if the comment has at least 1 tagged user.
  • Comments can be also filtered by optional query parameter readByAllTaggedUsers. Only those comments that have been read by all tagged users are returned. Comments without tagged users aren't returned.

Endpoints related to Dimensions

• We have added a new endpoint PUT /dimensions/{dimensionId} to update specific dimension's name. PUT /dimensions, which is currently used for this will be removed in future. This will be communicated later in advance.

Other endpoints

• Earlier when user had "No access" right to Sales or Purchases Product register, API returned 500 error when trying to add a new bank account via POST /bankaccounts. This has now been fixed and error isn't returned anymore.

Updates in API developers documentation

• Validation Error Codes page has been simplified. Model and Name columns have been removed from the table. Error description is now easier to find.

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 the rights property. This change is applicable only to the latest API version. The GET /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 accept String will accept one of these enum values NO_ACCESS, VIEWING_RIGHTS, ALL_RIGHTS, NOT_ENABLED. Please note NO_RIGHTS has been replaced by 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/old endpoint):

• In GET /invoices and GET /invoices/{invoiceId} endpoints we have now added an optional field invoiceSumInfo to return invoice's total sum. This is supported for all receipt types except PERIODIC_TAX_RETURN, which doesn't support invoice rows. To get additional information on excludingVatTotal and vatSumTotal, please use GET /invoices/{invoiceId} endpoint.
  
  If the invoice has currency other than the one set for the environment (when field inAccountingCurrency is false), it returns sum in both the accounting and invoice currency.

Updated API reference documentation

• Documentation for GET /invoices/personalapprovals and GET /invoices/personalverifications endpoints now correctly specifies that the types field is required (not type), and that it accepts multiple receipt types separated by a comma. Available values for types include PURCHASE_INVOICE, TRAVEL_INVOICE, and BILL_OF_CHARGES.
• Unnecessary mandatory fields uriParams and/or uriInfo 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 (this was removed in version 25.03).

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.

Older release notes

Older release notes can be found from their own page.

Old release notes