News

Information about future and past API releases

Home  ⫽ News

Version releases

We are constantly developing new features to Procountor API. This page presents the planned changes in future version releases as well as release notes from past ones. For all interested ones, we recommend subscribing to our mailing list to get notifications from changes to the API.

The currently available API versions are listed below.
API version Release date Support ends
latest monthly release with no extended support
20.04, supported 18-04-2020 mid-November 2020
20.01 18-01-2020 mid-August 2020
You can find the version update schedule from Procountor news and announcements site.
Procountor API version diagram

Future changes

We are changing the format of our API access and refresh tokens to JWT in August API release. This change will affect all API versions.

Any new access and refresh tokens issued by the API will be in the new format. The old format refresh tokens will continue to function normally.

The new tokens will contain additional information, including audience and expiration date, and will be longer in size than the current tokens; up to 512 bytes for access tokens and up to 1024 bytes for refresh tokens. Please ensure that your implementation is able to handle the longer tokens.

The following features are on the backlog of our development team but not necessarily with a confirmed schedule. They are presented in no specific order.

  • Machine-to-machine authentication improvements
  • New webhooks

Release notes

Changes highlighted in red are not backwards compatible

Changes in version 20.06

Endpoints

  • PUT /businesspartners/{id} - Renewed endpoint for updating business partners. The old functionality is available using PATCH /businesspartners/{id}.
  • The referenceCode field has been renamed to bankReferenceCode in GET /invoices/{id}, POST /invoices and PUT /invoices/{id} endpoints.
  • The generatedReferenceType field has been renamed to bankReferenceCodeType in GET /invoices/{id}, POST /invoices and PUT /invoices/{id} endpoints. If present, the value in this optional field is used to validate the value given in the bankReferenceCode field.

Changes in version 20.05

Endpoints

  • PUT /businesspartners/{id} endpoint has been changed to PATCH /businesspartners/{id}. The functionality remains the same.
  • The response models for GET /invoices/{id} and POST /invoices now show the same information. Missing fields were added to both models and the numeric precision in the existing fields was adjusted to match.
  • Address validation rules in POST /invoices and PUT /invoices/{id} now match the rules in the UI
  • POST /payments now correctly handles payment methods not allowed in the UI.
  • GET /users/rights - A new endpoint for getting access rights for the currently logged in user

Other

  • We have changed the way unset reference ids are returned by all API endpoints. In case the returned JSON object contains reference id field with no value the field will be returned as null. This changes the behaviour in some of the endpoints where 0 or "" value was returned before.
  • The following id fields can now be found with new names. The old fields have been marked as deprecated and will be removed in the future.
    Model / Schema New field Old field
    BasicPaymentTransactionData id paymentId
    BusinessPartnerBasicInfo id registerId
    FactoringContract id contractId
    LedgerReceipt id receiptId
    LedgerReceiptBasicInfo id receiptId
    PaymentEvent id paymentEventId
    PaymentRowInfo id paymentId
    PersonalDetails partnerId personId
    Transaction id transactionId
    User
     
    id
    partnerId
    userId
    personRegisterId
  • Number of previously generalized error conditions now return more specific error codes and messages.
  • Errors caused by failing validation rules have been clarified.

Changes in version 20.04 (supported)

Endpoints

  • GET /businesspartners/{id}/defaults/products - A new endpoint for getting the default products for a given business partner.
  • GET /businesspartners/{id}/defaults/accounts - A new endpoint for getting the default accounts for a given business partner.
  • POST /businesspartners endpoint has been extended to support all fields except id, attachments and version.
  • E-Invoice addresses given to business partners using POST /businesspartners or PUT /businesspartners/{id} endpoint are now validated against used environment and country.

Changes in version 20.03

Endpoints

  • PUT /invoices - A new endpoint for modifying existing invoices. The invoice type, status or attachments cannot be modified using this endpoint.
  • PUT /invoices/{invoiceId}/notes - A new endpoint for modifying the internal notes of an invoice.
  • PUT /referencepayments/metadata endpoint has been renamed to PUT /referencepayments/{referencePaymentId}/metadata.
    The targetResourceId parameter has been removed from the request body and reintroduced as the referencePaymentId path parameter. The request body now consists only from a list of AllocationMetadataRows.
  • DELETE /referencepayments/metadata/{referencePaymentId} endpoint has been renamed to DELETE /referencepayments/{referencePaymentId}/metadata.
  • PUT /invoices/pay endpoint has been removed. Note that this is different from POST /payments and PUT /invoices/{invoiceId}/payments/markpaid endpoints, which provide means to pay invoices or mark invoices as paid.
  • POST /payments - A new field has been added bankReferenceCodeType. If present, the information in this optional field is used to validate the value given in the bankReferenceCode field.
  • POST /payments/directbanktransfers - A new field has been added to the endpoint: bankReferenceCodeType. If present, the information in this optional field is used to validate the value given in the bankReferenceCode field.
    This field replaces the fikGikCode field. Implementations relying on fikGikCode must switch to this field, and its corresponding values: GIK01, GIK04, GIK15, FIK71, FIK73, FIK75.
  • POST /payments/directsalarypayments - A new field has been added: bankReferenceCodeType. If present, the information in this optional field is used to validate the value given in the bankReferenceCode field.
  • POST /payments - DENMARK_EXPRESS_PAYMENT is no longer a supported paymentMethod with this endpoint.
  • POST /payments/directbanktransfers - DENMARK_EXPRESS_PAYMENT is no longer a supported paymentMethod with this endpoint.
  • Invoice row ordering given to POST /invoices endpoint is now preserved.
  • Invoice rows returned by GET /invoices/{invoiceId} now follow the ordering given using the POST /invoices endpoint or in the UI.
  • GET ​/invoices​/{invoiceId}/paymentevents now returns description for the payment event.
  • PUT /invoices/{invoiceId}/payments/markpaid - It is now possible to mark credit invoices as paid (payments with negative amounts) using this enpoint.

Other

  • Marking sales invoices paid using PUT /invoices/<invoiceId>/paymentevents/markpaid no longer requires full rights for "Mark paid elsewhere". Viewing rights suffice just like in the UI.
  • API error messages have been clarified.

Changes in version 20.02

Endpoints

  • GET /invoices/{invoiceId}/paymentevents/{id} - A new endpoint for getting single payment events.
  • You can now use originalInvoiceNumber to filter results returned by GET /invoices.
  • Invoice rows returned by GET /invoices/{invoiceId} now have an unique id.
  • Field names in GET /businesspartners have been changed to match field names in GET /businesspartners/{id} as follows:
  • codeinvoicingInfo/identifier
  • codeTypeinvoicingInfo/identifierType
  • customerNoinvoicingInfo/customerNumber
  • activeregistryInfo/active

Other

  • Performance issues in GET /bankstatemets have been addressed.
  • Pagination related bug in GET endpoints' metadata has been fixed.
  • Electronic invoice address validation bug affecting Swedish environments has been fixed.

Changes in version 20.01 (supported)

Starting from January 2020, we will enforce a 100 refresh token limitation for (API client, company, user) -tuple. This means that a single user can have at most 100 valid refresh tokens for a single company using the same client software at a time. When new tokens are requested at the limit the oldest tokens get removed.

Starting from 1st of January 2020, the refresh token lifespan will be set to 6 months. The lifespan of tokens created before then is calculated from January 1st. This means that such tokens will expire 1st of July 2020 if not invalidated before then.

Endpoints

  • GET /factoringcontracts - A new endpoint for searching factoring contracts
  • POST /factoringcontracts - A new endpoint for creating factoring contracts
  • GET /status - An endpoint for checking the API health
  • PUT /referencepayments/metadata - A new endpoint for allocating VAT metadata to a reference payment
  • DELETE /referencepayments/metadata/{referencePaymentId} - A new endpoint for removing VAT metadata from a reference payment
  • You can now filter invoices returned by GET /invoices endpoint by factoring contract id.
  • PUT /invoices/{invoiceId}/paymentevents/markpaid now returns details of the created payment event.
  • You can now add factoring contract for business partners using POST /businesspartners and PUT /businesspartners/{id} endpoints.
  • You can now filter business partners returned by GET /businesspartners endpoint based on their modification date. The date of the last modification is also returned with every business partner.
  • Missing address.name field has been added to GET /businesspartners/{id} response.

Other

  • Field validations, error messages and documentation have been clarified.

Changes in version 19.12

Endpoints

  • DELETE /products/groups/{groupId} - A new endpoint for removing sales and purchase product groups from the product catalog
  • DELETE /products/{productId} - A new endpoint for removing sales and purchase products from the product catalog
  • We've added a custom ID field to direct salary payment lists. The custom ID can be up to 80 characters in length and can be used to filter the lists returned by GET /payments/directsalarypayments.
  • You can now filter the direct salary payment lists returned by GET /payments/directsalarypayments endpoint by name.

Other

  • The page titles in API login have been changed. The basic login page is now Finago login, the reset page (opened from the Forgot password? link) is Finago password reset and the API password changing page is now titled as Finago password change.
  • A bug where the TRAVEL products were not available from the API in some environments has been fixed.
  • A bug where an invoice creation is erroneously reported as failing when using limited dimensions has been fixed.
  • Security related fixes
  • Small bug fixes and improvements

Changes in version 19.11

Endpoints

Direct salary payments
  • POST /payments/directsalarypayments - A new endpoint for creating a list of direct salary payments which will be processed as a single bundle by Procountor and a bank. Requires 2-factor authentication.
  • GET /payments/directsalarypayments - A new endpoint for accessing created direct salary payment lists.
  • PUT /payments/directsalarypayments/{paymentlistId}/cancel - A new endpoint for cancelling a created direct salary payment list before it is being processed by a bank. Requires 2-factor authentication.
  • PUT /payments/directsalarypayments/{transactionId}/confirm - A new endpoint for following the status of direct salary payment transactions.
  • Two new webhooks related to direct salary payments
  • DIRECT_SALARY_PAYMENTS_CREATED for newly created payment lists
  • DIRECT_SALARY_PAYMENTS_CANCELED for cancelled payment lists
Product endpoints
  • GET /products - The endpoint now returns only SALES and PURCHASE products if a product type is not defined with the type query parameter. TRAVEL products are returned only when the queried type is set to TRAVEL. The startDate and endDate fields are only used with TRAVEL products.
  • GET /products/{productId} - The endpoint now returns startDate and endDate fields only for products whose type is TRAVEL.
  • GET /products/groups - We've renamed the productType query parameter to type in this endpoint. When type is not given the endpoint returns all SALES and PURCHASE product groups. TRAVEL groups are returned only if the type parameter is set to TRAVEL. A matching type field is also returned with all found product groups.
  • POST /products - A new endpoint for adding new sales and purchase products to the product register.
  • PUT /products/{productId} - A new endpoint for modifying existing sales and purchase products in the product register.
  • POST /products/groups - A new endpoint for adding new sales and purchase product groups to the product register.
  • GET /products/groups/{groupId} - A new endpoint for fetching details of individual product groups from the product register.
  • PUT /products/groups/{groupId} - A new endpoint for modifying existing sales and purchase product groups in the product register.
Other endpoints
  • POST /invoices - You can now use the paymentInfo/generatedReferenceType field to specify a type for an automatically created reference code when POSTing invoices.
  • GET /vats/default - We have added vatStatuses list to this endpoint. The list contains the valid VAT statuses for the active environment.

Other

  • A bug in the Invoices API where the user was not always able to fetch a purchase invoice after it had been verified has been fixed.
  • A bug where the user defined KID was substituted with an automatically generated one when POSTing an invoice in an Norwegian environment has been fixed.

Changes in version 19.10 (supported)

Starting from this release the API versioning will follow YY.MM convention. We are also making the API support cycle more consistent. We'll release a new latest version of the API every month. Every three months we release a supported version of the API, which will be available for the following six months.

Other

  • Calling ../{transactionId}/confirm endpoints is no longer necessary in order to execute an API transaction requiring 2-factor confirmation. The confirm endpoint still returns the status of the transaction like before, but the transaction itself is completed once the user accepts it in Finago key application. Changes in a transaction status can be received using webhooks, and the status will also be available through the confirm endpoint for 24 hours from the start of the transaction.
  • We have enhanced the documentation of the webhooks

Older release notes

Older release notes can be found from the older release notes page.