1. Home
  2. Docs
  3. Documentation
  4. FAQ
  5. General


Why are there required fields in sub-objects in Swagger?

This is due to how our DTOs are set up. When you open a sub-object in Swagger you may notice that some fields are mandatory, however this is only true if you are creating a new object, not when referencing an existing one. Let’s look at an example from POST ledger/voucher:

If we want to add a posting to our voucher we need to specify the account to use, but in Swagger you will find that it looks like this:

Understandably you might want to use the name and number in this request, however that will lead to errors (mostly of the “not found”-variety). To reference an existing object the general rule of thumb is to use ID, like so:


The reason our DTOs are set up like this is that it makes it a lot easier to work with generated clients, however we do understand this is confusing.

I specified “Count” to be less than 10.000 but I still get “Result set too large. Limit of 10.000 reached.”, why?

For many this might look like a bug, however the count parameter never really limits your request in terms of what you fetch from the database, only how many objects are returned in the response. Thus count does not limit you in terms of the object limit, only what is delivered in your response. You need to use other parameters (date, account etc) to make sure you fall below the 10K object limit.

What does the error “ID kan ikke settes når man oppretter et objekt.” mean?

This error indicates that you can not set an ID when creating a new object (in case of POSTs). ID and version should never be defined in a POST requests as these values are defined by the system upon creation (also PUTs when it comes to version).

What does the response “Object not found” mean?

Most likely you are referring to an object without the internally assigned ID of the object. When you create i.e a customer and you want to post an order with this customer, you have to refer to the customer.Id. This relates to all objects in the Tripletex API. This can also occur if you refer to an ID that does not belong to the company that you are currently authorized as (where your employee token was created). You will only be able to see data that belongs to the company you are authorized as.

If you want to know the ID of an object, GET the data from the relevant endpoint.

According to swagger I am providing a valid value to an attribute, but I still get a validation error, why?

As Tripletex is an accounting software certain validations are in place to prevent invalid data being passed. Let’s take the “organizationNumber” attribute from the customer endpoint as an example. Here you will see in Swagger that the expected value is a string with maxLength=100. If you try to pass a swedish organization number here (for example 123456-1234) without setting the customers location to Sweden you will get an error saying it is invalid. There are more examples of this, but a useful tip is to attempt the same action in the GUI to see if it is allowed there – If it is then please report the error to us.

How can I use the fields parameter to increase the effectivity of GET requests?

This example is fetching orders via /v2/order. Without usage of fields you will get a dataset returned which includes information about the order objects, i.e our internal ID, order number, delivery date, ID of the customer on the order and a list of internal IDs of the order lines.

This would suffice when you only want the data for the order. As an example, the API request is GET /v2/order?orderDateFrom=2017-01-01&orderDateTo=2017-02-01.

If you want the order lines related to the order as well you can expand the API request by specifying fields like *,orderLines(*). This means get all fields on order (*), as well as all fields on every order line (orderLines(*)). This will return description, count, price etc on every order line in addition to the internal ID. This API request is: GET /v2/order?orderDateFrom=2017-01-01&orderDateTo=2017-02-01&fields=*,orderLines(*)

Can I get hidden fields for our internal ID’s or other information?

We inherently do not wish to support fields for this, we recommend that you instead save our ID’s for your system and make the relation that way if possible.

Was this article helpful to you? Yes 2 No