Tripletex API Integration
Tripletex is a Norwegian cloud accounting platform used from sole traders to mid-sized firms, with an API and a developer programme of its own. Connect it through Maesn and you reach it with the same REST API and the same data model as every other supported system.
A Tripletex integration in days
Tripletex is well documented, and three of its specifics land on your engineers before anything useful happens. Here they are, and here is what Maesn takes off the table.
The session token is held here
Tripletex combines two tokens into a third: a consumer token that identifies your integration, and an employee token your customer creates in their own Tripletex. Together they produce a session token, which is what every later call actually carries and which is created with an expiry date rather than a duration. Maesn derives it, and derives a new one when it runs out.
The row numbering happens here
Updating a journal entry in Tripletex works by id for lines that already exist, but a line you are adding has no id yet and has to carry its row number instead. Maesn has no row field to hand you, and inventing one would push that bookkeeping onto your schema. So before the update goes out it reads the entry, takes the rows already in use and numbers the new line itself. Your code just sends the line.
Resolved once, at connection time
Tripletex puts the target company where most systems put an identity: the username half of the authentication header. A plain employee sends zero and gets their own company. An accountant sends a company id instead, and has to know which ids they may use. Maesn settles that when the connection is made, so your requests carry an account key and never a company.
What is left on your side is one REST call against a data model you implement once. A Norwegian customer stops being a reason to open a second project.
The second of those three is the one that surprises people, because nothing about it looks like a problem until the first update fails. Adding a line to an existing journal entry is not addressed the way the rest of the object is: existing lines are found by their id, but a line that does not exist yet has to announce which row it will occupy. Maesn reads the entry, sees which rows are taken and numbers the new one before the write goes out, so that logic never reaches your code. When something does go wrong further along, one error model across the catalogue means one status and one body to read, so Tripletex belongs in your support runbook and not in a branch in your client.
A short call is usually enough to tell whether Maesn fits your use case.
Three reasons to reach the Tripletex API through Maesn
Connecting Tripletex directly is a project a good engineer can finish. Holding its two token exchange for a year, keeping its row numbering correct on every write and then doing the same again for the next system is the part that decides your roadmap.
The Tripletex work stays here
The two token exchange, the session that is created with an expiry date, the accountant who has to pick a company and the row numbering on every journal update are what every Tripletex integration has to solve. They are solved once, here, for every customer you connect.
Live today, reads and writes
Accounts, journal entries and tax rates are readable on the connection, and journal entries can be created and updated through it. That is a working posting path, not a read-only view. The rest of the catalogue is available on request, so tell us what your use case needs and we will confirm it before you build.
The next system costs nothing
Once Tripletex runs, every other supported accounting and ERP system answers on the same interface, with the same data model behind it and the same two headers in front of it. Your second integration is a configuration step, and your engineers reuse what they learned here.
Two Tripletex tokens, and the one we make from them
Tripletex authenticates with a token your customer holds and a token you hold, combined into a session token that carries every later call. Maesn does the combining. What is worth knowing before you design your onboarding is that Tripletex treats a single company and an accounting office differently, and that difference reaches the request itself.
- Two tokens combined into a session
- Headless or interactive
One implementation, and the accountant case is part of it.
- Single company or accounting office
- Tripletex has two of them, and the difference is not cosmetic. An employee logs in and is always inside one company. An accountant reaches many, so one of them has to be chosen, and Tripletex publishes a dedicated call that lists the ones a given login may use. Maesn makes that call and settles the choice while the connection is being made, so the multi-entity case costs you an onboarding decision rather than a code path.
- Two ways to collect the token
- Because the employee token is a value your customer already has, Tripletex is on both of our authentication paths. You can send them to a Maesn page that asks for it, or you can ask for it inside your own product and pass it straight to the API, which returns the account key without a page of ours in between. The second keeps your onboarding entirely in your own interface.
The session token behind all of this is created with an expiry date, so it is finite by design rather than by revocation. Maesn derives a new one when it expires, which is why the account key you hold does not change when it does.
- 1
Your customer enters their employee token
They create it in their own Tripletex under user settings and API access, and enter it either on a Maesn page or inside your product. It is one value, and there is no password of theirs anywhere in the exchange.
- 2
Maesn combines it with your consumer token
Your consumer token is already configured on your tenant, so the two meet on our side and produce the session token Tripletex expects. Your consumer token never travels through your front end, and your customer never sees it.
- 3
You work with one account key
Maesn stores the connection and returns an account key. From there every request carries your API key plus that account key, the same two headers you already send for every other system in the catalogue.
It is worth being concrete about who holds what, because the split is unusual. Your consumer token is yours and identifies your product to Tripletex across every customer you connect. The employee token belongs to the customer, is created inside their own Tripletex and never becomes yours. The session token that actually carries the traffic exists only because both were present, and it is created with an expiry date rather than a duration. Unified authentication is what makes that a detail rather than a design problem: the exchange, the session and the account key behave the same here as on a system with a plain redirect, so your product sees one connection story across every system it reaches.
What Tripletex publishes, and what you schedule
Tripletex publishes a real event system, and Maesn does not put it in front of you today. Change detection on this connection is a scheduled read, and you run it the same way you run it everywhere else.
A subscription model where an event names an object and a verb, so creating, updating and deleting are three separate subscriptions on the same object. A delete arrives without the object: you are told which id went away, not what it contained.
One scheduled read with the pagination you already use everywhere else. The loop pointed at Tripletex is the loop pointed at every other system, so the schedule is written once and you change the account key. What changes between systems is the interval.
A scheduled read also catches up cleanly after downtime, where a missed push is simply gone. Tripletex counts its rate limit per employee and per consumer rather than per company, and it tells you where you stand in three response headers on every call, so a read loop can pace itself against the actual budget instead of a documented guess.
The practical consequence is that Tripletex does not need one schedule for everything. A chart of accounts and a tax rate list settle for months at a time and can be re-read whole overnight. Journal entries move with the working day and earn a shorter interval. Sizing both the same way means paying for a full pass you did not need or seeing yesterday’s bookings a day late, and neither is a property of the connection.
What makes both of them cheap is that neither is Tripletex-specific code. One way to filter and page means the loop pointed at Tripletex is the loop pointed at everything else. And it keeps working the day those events are switched on for you, because the event model is a separate path and not a replacement for this one. You write the schedule once and change the account key.
What a Tripletex connection asks for up front
Tripletex puts three things in front of an integration, and only one of them is yours to do more than once.
- Your own consumer token, once
- Tripletex issues a consumer token per integration, not per customer, and yours is the one that identifies your product across all of them. You request it from Tripletex and hand it to us once, and we configure it on your tenant. Nothing about that step repeats per customer.
- A test environment, which arrives quickly
- Tripletex runs a separate test environment with its own consumer and employee tokens, and ours came back quickly with a test login to go with it. Maesn reaches it as its own target system, so you can build and test against it before a real customer is involved.
- Your customer's employee token, with its entitlements
- Each customer creates their own employee token in Tripletex under user settings and API access, which needs an administrator on their side. Tripletex expects that token to be given a set of entitlements when it is created, so it is worth telling your customer which data you will be reading before they make it. That token is the one value they enter when they connect, and it stays theirs.
We go through the consumer token and the object list with you before you start building.
A Tripletex journal entry arrives in one shared shape
Tripletex carries its journal lines in an array on the entry, counts in a field it is retiring, and keeps a Norwegian amount beside whatever currency you posted in. All three reach your schema, so it helps to see them before you map anything.
The total count is on its way out
Tripletex paginates natively, and its response envelope still carries a field for the size of the full result, marked deprecated in its own documentation. On the accounts endpoint our engineers found no total coming back at all. Maesn paginates that read itself rather than trusting a number that is being retired, so what you receive is a complete list either way.
Every entry has a Norwegian side
Tripletex books in Norwegian kroner underneath whatever currency you chose, and shows both. The practical consequence is on the way in rather than on the way out: posting an entry in euros or dollars means sending an exchange rate along with it, because the system has to express that entry in kroner as well before it will accept it.
Whatever you read comes back in the shared common data model, so a journal entry from Tripletex has the same shape as one from a system ten times its size, and the code you write here is the code you reuse for the next one. Tripletex makes that mapping easier than most: its entry carries its postings as an array on the object, which is close to how the shared model already describes one.
The part that reaches your schema is the currency. Tripletex expresses every entry in Norwegian kroner underneath the currency you chose and shows both, which means posting in euros or dollars is not complete without an exchange rate to go with it. That is a decision about your own data before it is a mapping question, and it is the same decision whether you reach Tripletex through us or directly. Within the Visma group it is also the thing that most distinguishes this system from its siblings on the Visma integration overview.
Tell us which objects your use case needs and we will confirm what is possible.
