Requests

Throttling

The default product subscription provide a throttling with a limit of 10 requests per second, for each subscription key (regardless of the number of client integration instances, ie clientkey's). You should keep the number of requests to the miminum needed for your workflow.

If you do reach the limit, the HTTP request will be answered with the HTTP response code "429 - Too Many Requests". The best practice for handling this situation is to wait at least one second and then retry the request.

Access token renewal

It is recommended to be proactive when renewing access token.

1. Renewing the access token after getting an unauthorized request:

   This approach is reactive. You make a request with the current access token, and if you get an unauthorized (401) response, you then renew the token and retry the request. This approach can be simple to implement, however, it can lead to many failed requests and a slightly worse user experience if a request fails due to an expired token. It will also potentially lead to more request being sent to the API-server, which should be avoided.

2. Ensuring that you always have a valid access token before sending requests:

   This approach is proactive. You keep track of when the access token is going to expire and renew it before this happens, or before you do a request. This approach can provide a smoother user experience because it can prevent requests from failing due to expired tokens. However, it can be more complex to implement because you need to accurately track token expiration times and handle token renewal at appropriate intervals.We recommend the proactive token strategy, as this will reduce the amount of requests needed to be sent. As mentioned above, there is a throttling limit on the API, and all actions that help to avoid reaching the limit is recommended.

Fields

Retrieve only what you need, by using the fields filter parameter to define the response. This will reduce the payload of the response and reduce the impact of the systems in both ends.

Database validation

Many endpoints have an optional filter parameter with <useDatabaseValidation>. This parameter is default false (not used), meaning that the general filtering used in the api requests, are not validated with "404 - not found" errors. If you, for instance, filter on a project code that does not exist, the response will return empty without any validation.

Setting the filter parameter <useDatabaseValidation> true, will enable validation of the filter parameters. Using the same example as above, the response "404 - not found" will be given. Please note that enabling this parameter and implementing database validations may significantly affect response time. The use of the <useDbValidation> parameter should be limited to cases where it is necessary, such as for support handling.

User agent header

Although it is not required, we highly recommend that you set an identifying user-agent string in the header of your requests, including your application/domain name and an email address. An identifier will make it substantially more efficient for us to handle any support cases, should they arise.

Live data and filtering

All GET requests are performed towards a replicated database on our side. This means there is a small synchronization delay between storing and retreiving data. Typically this delay is below 1 second. To ensure that you retreive the most up-to-date data when synchronizing with Go, we recommend waiting 1-2 seconds after a POST/PATCH/DELETE has been performed on a dataset, before calling a subsequent GET request on the same data.

To obtain the latest data, we typically recommend using the lastChangedDateTimeOffset properties, if available (or the createdDateTimeOffset if applicable). These properties denote the timestamp of the entity/object's most recent change (or creation) in the database. By tracking the last time a request was made to retrieve the latest data and filtering subsequent requests based on lastChangedDateTimeOffset later than that time, only data that has been updated since the previous request will be retrieved.

A special note on account transactions and <AccountTransactions endpoint>: Only the description field can be changed on vouchers already posted in Go. Any other change that involve a change of the accounting information, will automatically generate a reversal voucher (reversing the original) and a new voucher with the corrections made. For all practical purposes, the best way of retreiving new accounttransactions will then be to use a broad date range, and filter on voucherNo > "the last registered voucher number you have". This will ensure that you always retreive all new vouchers with their transactions, depending on the page size.

Paging

The API have a default page size of 5.000 entries, and in general a max page size of 20.000 if you need to increase the page size. We regularly monitor server load and may adjust the maximum page size of endpoints as needed to optimize performance.

The api response will provide a link to the next page and previous page in the x-pagination header, whenever the dataset is larger than the page size set in the api call.

It is preferable that you keep the page size to the minimum required for your workflow.