How to Integrate with the Tripletex API

Step-by-step guide to integrating with the Tripletex API — token auth, session management, core endpoints, webhooks, and production access in one guide.

Saurabh RaiSaurabh Rai

Saurabh Rai · Developer Relations Engineer, Apideck

10 min read
How to Integrate with the Tripletex API

Tripletex is the accounting platform that owns the Norwegian SMB market. With 150,000 customers as of late 2025 and Visma's acquisition in 2016 bringing deeper engineering investment, it's a required integration for any SaaS product serving Nordic customers. The API covers the full accounting lifecycle: customers, suppliers, orders, invoices, vouchers, hours, projects, and inventory.

This guide walks through the complete integration path, from setting up a test environment to production approval, with working code examples for authentication and the endpoints you'll use most.

Auth note: Tripletex does not use OAuth 2.0. It uses a proprietary two-token system where a consumer token and an employee token are combined to generate a session token. That session token is then used as the password in HTTP Basic authentication. The setup is different enough from standard OAuth flows that it trips up developers who assume they can reuse boilerplate. Read this section carefully before writing any code.

Prerequisites

Before you start:

  • A Tripletex test account, registered at api-test.tripletex.tech. You get both tokens and an activation email on signup — the test environment is fully self-service.
  • Familiarity with HTTP Basic authentication and REST APIs.
  • A decision on integration scope: are you integrating for a single company (regular employee token) or building a multi-client accountant integration (accountant token)? The auth flow differs.
  • For production: a submitted access application. Approval takes 2–3 weeks with no expedited option.

Step 1: Create a test account

Go to api-test.tripletex.tech and register. You'll receive:

  • A consumer token — this identifies your application. One token per integration, shared across all end users.
  • An employee token — this represents the user within a specific company. End users create their own employee tokens from the Tripletex GUI in production; in the test environment you get one automatically.
  • An email for user activation.

Test credentials only work against api-test.tripletex.tech. They will not work against the production API at tripletex.no, and vice versa. Keep them in separate environment variable files.

Test accounts stay active for six months. If you lose your tokens, Tripletex cannot recover them. Create a new test account to get fresh ones.

Step 2: Generate a session token

The session token is created by combining your consumer token and employee token in a single API call. You exchange these credentials once to receive a session token, which you then use for all subsequent requests.

Session tokens expire at midnight CET on the expiration date you specify. The API does not issue refresh tokens — you generate a new session token before the current one expires.

curl -X PUT \
  "https://api-test.tripletex.tech/v2/token/session/:create?consumerToken=YOUR_CONSUMER_TOKEN&employeeToken=YOUR_EMPLOYEE_TOKEN&expirationDate=2026-05-10" \
  -H "Content-Type: application/json"

The response contains your session token:

{
  "value": {
    "id": 12345,
    "token": "eyJjb25zdW1lclRva2VuIjoiYWJj...",
    "expirationDate": "2026-05-10"
  }
}

In Python:

import requests
from datetime import date, timedelta

CONSUMER_TOKEN = "your_consumer_token"
EMPLOYEE_TOKEN = "your_employee_token"

tomorrow = (date.today() + timedelta(days=1)).isoformat()

response = requests.put(
    "https://api-test.tripletex.tech/v2/token/session/:create",
    params={
        "consumerToken": CONSUMER_TOKEN,
        "employeeToken": EMPLOYEE_TOKEN,
        "expirationDate": tomorrow
    }
)

session_token = response.json()["value"]["token"]

Store this session token. You'll use it as the password in every subsequent request.

Step 3: Authenticate requests

Tripletex uses HTTP Basic authentication for all API calls after session creation. The username is 0 (zero), which tells the API you want to access the company owned by the employee token. The password is the session token.

import requests

session = requests.Session()
session.auth = ("0", session_token)

# Test it with a simple company info request
response = session.get("https://api-test.tripletex.tech/v2/company")
print(response.json())

If you're building an accountant integration — where your application accesses multiple client companies through one accountant user — the username is not 0. You first call GET /company/>withLoginAccess to get the list of accessible companies, then use the company ID as the username for subsequent requests to that company's data.

Step 4: Core endpoints

The Tripletex API covers most accounting objects. The OpenAPI documentation is the canonical reference, with interactive testing built in.

The endpoints you'll use most in standard SaaS integrations:

Invoices and orders

GET  /v2/invoice          # List invoices with filters
POST /v2/invoice          # Create an invoice
GET  /v2/invoice/{id}     # Get a specific invoice
PUT  /v2/invoice/{id}     # Update
GET  /v2/order            # List orders
POST /v2/order            # Create an order

Customers and suppliers

GET  /v2/customer         # List customers
POST /v2/customer         # Create a customer
GET  /v2/supplier         # List suppliers
POST /v2/supplier         # Create a supplier

Ledger and vouchers

GET  /v2/ledger/voucher   # List vouchers
POST /v2/ledger/voucher   # Create a voucher (bookkeeping entry)
GET  /v2/account          # Chart of accounts

Products and inventory

GET  /v2/product          # List products
POST /v2/product          # Create a product
GET  /v2/inventory        # Inventory records

Tripletex supports the fields parameter on GET endpoints to limit response size:

GET /v2/customer?fields=id,displayName,email

Use it. Responses without field filtering return the full object graph, which is large for customers and orders. On high-volume syncs, the bandwidth and processing overhead adds up.

For date-range filtering on orders:

GET /v2/order?orderDateFrom=2026-01-01&orderDateTo=2026-03-31&isClosed=false

Step 5: Sync data with webhooks

Polling is the wrong sync pattern for Tripletex. The API has a full webhook system with guaranteed delivery, which means you should use it for anything that updates frequently: invoices, payments, orders.

Subscribe to events by registering a webhook endpoint:

response = session.post(
    "https://api-test.tripletex.tech/v2/event/subscription",
    json={
        "event": "v2.Invoice.*",  # Covers create, update, delete
        "targetUrl": "https://your-app.com/webhooks/tripletex",
        "fields": "id,status,amountIncludingVat"
    }
)

Available event namespaces include v2.Invoice, v2.Order, v2.Customer, v2.Supplier, v2.Voucher, and more. Wildcards (v2.Invoice.*) subscribe to all event types within that namespace.

Tripletex guarantees webhook delivery as long as your endpoint is available. If your server is offline temporarily, events are queued and retried. Set up proper HTTP 200 acknowledgment on receipt — the system treats anything other than 2xx as a failure and retries.

For smaller or infrequently changing datasets, the checksum API gives you a hash of a dataset. Compare the hash on a schedule; if it changes, pull the delta. This works well for product catalogs and chart of accounts where webhooks would be over-engineered.

Step 6: Apply for production access

Tripletex requires a formal application before you can use the production API at tripletex.no. Submit the production access form after you've finished testing. You'll need to describe your integration, your application name, and your use case.

The approval takes 2–3 weeks for everyone, no exceptions. Plan your launch timeline accordingly. Once approved, you receive a production consumer token via email along with your official application name in the Tripletex ecosystem. End users then generate their own employee tokens through the Tripletex GUI by selecting your application name from the dropdown.

Common gotchas

Test and production tokens are completely separate. This is obvious in retrospect but causes real problems when developers test successfully and then deploy. Your test consumer token will fail against tripletex.no. Your production consumer token will fail against api-test.tripletex.tech. Use distinct environment variables and fail loudly on startup if the wrong base URL is configured.

Session tokens expire at midnight CET, not 24 hours from creation. If you create a session token at 23:50 CET with an expiration date of today, it expires in 10 minutes, not 24 hours. Set expiration dates relative to CET, not UTC, and build in a buffer. A background job that regenerates the session token once per day at a fixed time in the morning is the simplest approach.

Employee tokens inherit the owner's permissions. If a user creates an employee token with "All entitlements" but they don't have those entitlements themselves, the excess permissions are granted but disabled. Your API calls will fail on those scopes. The fix is to either get the user to grant the correct entitlements on their account, or scope your token request to only what you need.

Application name is case-sensitive. When end users create employee tokens in the Tripletex GUI without your application in the dropdown (using "Adapted setup"), they have to type your application name exactly as registered. A single capital letter difference means Tripletex won't recognize the token as belonging to your integration. Make this instruction explicit in your onboarding flow.

Accountant token access doesn't work with username 0. If you're using an accountant token to access client companies, every request to a specific client's data needs that client's company ID as the username. Using 0 will either return the accountant's own (usually empty) account data or return an error, depending on the endpoint.

The OpenAPI docs have two instances. The test environment documentation is at api-test.tripletex.tech/v2-docs/ and the production docs are at tripletex.no/v2-docs/. They're nearly identical, but when debugging, make sure you're reading the documentation for the environment you're testing against. Credentials authenticated in one environment won't work in the other's documentation either.

Security practices

Store your consumer token in an environment variable, never in source code. It's a long-lived credential that applies across all your end users — a leak affects everyone connected to your integration.

Scope employee token permissions to what your integration actually needs. If you only sync invoices and customers, don't request voucher or payroll access. End users are more likely to approve and less likely to revoke tokens with a narrow scope.

Set session token expiration dates intentionally. A session token that expires in 30 days and isn't refreshed will break your integration silently at midnight on day 30. Build explicit token lifecycle management into your integration layer: track expiration dates, refresh proactively, and surface connection errors to users when tokens expire unexpectedly.

Use separate test and production configurations in your deployment pipeline. Environment-level validation on startup prevents deploying test credentials to production or accidentally writing to production data during development.

What to build toward

For teams building integrations across multiple Nordic or European accounting platforms alongside Tripletex — Exact Online in the Netherlands and Belgium, Yuki for Dutch bookkeeping workflows, or Visma's own eAccounting platform under the Spiris brand — the maintenance cost of managing separate authentication flows and data models adds up quickly.

The complete guide to accounting API integrations covers the architecture decisions that matter when you're supporting more than one platform: how to isolate your integration layer, handle partial failures across systems, and structure your data models to avoid per-platform branching in your core product.

Apideck doesn't yet have a Tripletex connector on its unified accounting API, though Tripletex support is in the pipeline. If you're integrating with QuickBooks, Xero, or other major accounting platforms alongside Tripletex, the unified API approach can handle those connections through a single normalized interface while you manage the Tripletex integration directly.

Ready to get started?

Scale your integration strategy and deliver the integrations your customers need in record time.

Ready to get started?
Talk to an expert

Trusted by fast-moving product & engineering teams

JobNimbus
Blue Zinc
Exact
Drata
Octa
Apideck Blog

Insights, guides, and updates from Apideck

Discover company news, API insights, and expert blog posts. Explore practical integration guides and tech articles to make the most of Apideck's platform.