How to integrate with Tripletex: Three tokens, and a row number you never send

Tripletex does not hand out one credential. Before anything runs you need two, and they come from two different places: one is issued to you as the builder, the other is created by the customer whose data you are reading.

The one that is yours is the consumer token. Tripletex issues it once your registration for version 2 of the interface is complete, and it identifies your integration across every customer you will ever connect. It is not per customer and it is not per company. Treat it the way you treat any application secret.

The one that is theirs is the employee token, created inside the customer’s own Tripletex under user settings and the API access tab. That needs an administrator on their side, and it is worth knowing before you write the onboarding copy that tells them to go and make one.

There is a separate test environment with its own consumer and employee tokens, and it behaves like production against Tripletex’s test estate rather than a mock. Ours came back quickly. That is worth saying because it is not the norm in this corner of the market: several Nordic systems make you wait days, or require a national identity scheme before they will talk to you at all.

The consumer token and the employee token are not credentials you send. They are inputs. You exchange them for a session token, and the session token is what every later request actually carries.

The exchange is a single call that takes three required values: your consumer token, an employee token that was created against that same consumer token, and an expiration date. All three are mandatory, and the third one is the part that surprises people. You are not given a lifetime, you choose one.

From there, authentication is plain Basic access authentication with the session token as the password. If you are assembling the header yourself it is the company identifier, a colon and the session token, Base64 encoded. There is also a call to delete a session explicitly, which is the clean way to end access rather than waiting for the date to pass.

Through Maesn none of this reaches you. Your consumer token is configured on your tenant once, your customer enters their employee token when they connect, and the session is derived here and derived again when it runs out. Unified authentication is why that looks the same as a system with a plain redirect: what you hold afterwards is an account key, and account keys behave identically across the catalogue.

Tripletex has two kinds of login, and the difference is not a permission level. It decides how many companies are reachable at all.

Log in as an employee and you are always inside one specific company. That is the single-entity case, and there is nothing to choose. Log in as an accountant and you reach many, which is the multi-entity case, and now something has to say which one you mean.

Tripletex puts that somewhere most systems do not: the username half of the authentication header. Zero or blank means the company of the employee whose token you are using. Any other value means one of an accountant’s client companies, and there is a dedicated call that lists the ones a given login may access.

Through Maesn the choice is made when the connection is created, and the resolved company travels with the account key rather than with your requests. That is the whole of it on your side, and it is the same shape of answer you get on any system in the catalogue that has a tenant concept.

This is the one that fails quietly the first time, and nothing in the shape of the object warns you.

A journal entry in Tripletex carries its lines as an array on the entry itself. Updating a line that already exists works the way you would expect: you supply its id and the fields you are changing. Adding a new line does not, because a line that does not exist yet has no id to supply. What Tripletex wants instead is its position. If the entry already holds three lines, the one you are adding announces that it is row four.

That means you cannot construct the update from the data you are writing. You have to know what is already there, which makes a read the unavoidable first half of every write.

Through Maesn there is no row field in the shape you send, and there is no version for you to carry. The read happens before your write goes out, the rows in use are counted and the new line is numbered here. It is a small piece of machinery and it is the kind that is easy to get almost right: numbering from the count rather than from the highest occupied row is correct until someone deletes a line.

Tripletex pages natively and does it well. A list call takes a start index and a count, and the response comes back as an envelope with the values inside it. It also takes a sorting pattern and a fields parameter that selects which attributes you want back, including attributes of nested resources, which is more control than most systems in this category offer.

Filtering is typed and specific to the endpoint rather than generic. The accounts endpoint alone accepts filters on identifier, number, whether the account is a bank account, whether it is inactive, whether it is applicable for supplier invoices, its ledger type, whether it is a balance account, and its SAF-T code.

The one thing not to build on is the total. The envelope carries a field for the size of the full result, and Tripletex marks it deprecated in its own documentation. On the accounts endpoint our engineers found no total coming back at all, which is why the pagination over that read is ours rather than theirs.

Writing that loop once per system is exactly the work that one way to filter and page removes. The loop you point at Tripletex is the loop you point at the next system, and a deprecated count on one endpoint of one system stops being something your code has to know.

Tripletex publishes a genuine subscription model, which is not something every system in this catalogue can say. An event names an object and a verb together, so creating, updating and deleting the same object are three separate subscriptions rather than one stream you filter.

The delivery carries the subscription it belongs to, the event name, the identifier of the object it concerns and the object itself. With one exception: on a delete the object is null. You are told what went away, not what it contained, so anything your product needs to know about a deleted record has to have been stored before it went.

Those events are not switched on through Maesn today, so change detection on this connection is a read on a schedule you choose. They are available on request, and the schedule you write now keeps working either way, because the event model is a separate path rather than a replacement for polling.

Everything above is real work, and most of it is the same work for every customer you connect. That is the part to do once.

The objects reachable today are a smaller set than Tripletex as a whole. Accounts, journal entries and tax rates are readable, and journal entries can also be created and updated, which is a working posting path rather than a read-only view. The rest of the catalogue is available on request, and which parts you need is worth settling before you design around it. The scope, and what it takes to widen it, is on the Tripletex API page.

One thing genuinely stays yours whichever route you take. Tripletex expresses every entry in Norwegian kroner underneath whatever currency you posted in, and shows both. Posting in euros or dollars therefore means sending an exchange rate with the entry. No integration layer can decide which rate your business should use, so that is a decision about your own data rather than a mapping problem.