We have a rate limit of 100 request a minute pr. organization, on a ClientID basis.
If you hit the rate limit, this is the body of the HTTP 429 message that you will see: API calls quota exceeded! (...)
We constantly monitor the usage of our API to ensure that it is used as efficient as possible. If we detect that the API can be used more efficient or that the API resources are being exhausted by a single client integration and it is evaluated by Dinero to hurt the general service of the API to other customers, Dinero can decide to revoke the access for single clients.
You can also expect action to be taken, if you hit a lot of 400, 401 or 403 requests. We expect you to mitigate this on your end.
Dinero will always strive to solve such issues in dialog with the integrating partner before any counter measures are taken.
One of the harder parts of REST API's are images, because they require some extra steps. Here is a CURL example of image upload:
POST https://api.dinero.dk/v1/[organization_id]/files/?fileName=sample-invoice.jpg HTTP/1.1 Authorization: Bearer eyJ0eXAiOiJKV1QiLC.... Accept: application/json Content-Type: multipart/form-data; boundary="-------abcdefg1234" Host: api.dinero.dk Content-Length: 313036 Expect: 100-continue Connection: Keep-Alive ---------abcdefg1234 Content-Type: image/jpeg Content-Disposition: form-data; name=image; filename=sample-invoice.jpg; filename\*=utf-8''sample-invoice.jpg [ReplaceWithYourImage] ---------abcdefg1234--
Luckily this is all extremely well documented online, and you can easily search REST Image upload to find some great resources.
IMPORTANT❗ Files will not be accessible for the user, until you actually attach them to something like a purchase voucher, a manual voucher or a ledger item. Make sure you use the file for something.
Filters are not available on all properties, so be sure to check the endpoints queryFilter URI parameter description to see which. If the endpoint do not contain a queryFilter URI parameter, then it does not support filtering.
Each filter command is built after the structure:
Be aware that the [Value] is not case sensitive.
Each filter command should be separated with: ;
|Equals||string, int, bool||eq||Name+eq+’John Doe’|
GET methods, that potentially have a very large output, implements pagination. It can return a maximum of 1000 entries per page. If a higher pageSize is given an Exception with error code 43 is thrown. The pagination defaults to a pageSize of 100 entries, and returns the first page if left empty.
The pagination URI properties are listed below:
|page||The 0-based page number||integer||Default value is 0|
|pageSize||The maximum number of items to include in a page. Max 1000.||integer||Default value is 100. Max value is 1000.|
Use the most specific endpoint
In most cases, we recommend using the endpoints which our users would use themselves in app. That means, if you want to book an expense, choose something specific to that. For expenses that would be a purchase voucher.
Sales and invoices
If you need to book a sale, it might make sense to do it as an invoice, if you don't generate one on your end.
If you create the invoice on your own end, it would make sense to book it as a manual voucher, uploading your invoice as a file, and attach that to the manual voucher.
Does your integration book daily sales, then it would probably make sense to create a manual voucher as well, and probably a few extra accounts for credit card, mobilepay etc.