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.

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.