Visma e-conomic API Integration: Token Auth, Invoice Lifecycle, Dual-API Architecture & Danish Accounting Model Explained
- Dr. Themo Voswinckel ⎪Co-Founder
- 1 day ago
- 8 min read
Visma e-conomic is one of the leading cloud accounting platforms in the Nordics, widely adopted in Denmark, Norway and beyond by SMEs for invoicing, bookkeeping, and financial reporting. For software teams that need to integrate with their customers' accounting data, e-conomic is an important target system and one with several non-obvious technical characteristics that can slow down integration development significantly.
In this article, you will learn exactly where engineering teams run into friction when building a direct e-conomic integration: the proprietary token authentication model, the strict invoice lifecycle, the split between the REST API and the newer OpenAPI, the role of module-based access control, and the Daybook/Journal flow for bookings. For each challenge, we explain how Maesn abstracts it so your product stays target-system-agnostic and ready to scale.
Key Takeaways
Visma e-conomic uses a proprietary two-token auth model, not standard OAuth 2.0. Every request requires both an X-AppSecretToken and an X-AgreementGrantToken and each of your customers needs their own grant token.
Invoices live in two separate endpoints - invoices/drafts and invoices/booked - and once booked, they are immutable. Corrections require credit notes, and the API has no PATCH support.
There are two active APIs: the classic REST API (restapi.e-conomic.com) and the newer OpenAPI (apis.e-conomic.com). Pagination behavior differs between them, and certain functionality only exists in one or the other.
Creating objects requires resolved references first. Layout, payment terms, VAT zone, currency, and account references must be fetched per tenant before you can create an invoice or customer.
e-conomic has a module-based access model. If a customer does not have a specific module enabled (e.g., Projects, Inventory), the related API endpoints will return errors — not empty results.
The Daybook (Kassekladde / Journal) is the standard booking mechanism in Danish accounting. e-conomic supports this via REST, and your integration architecture must account for it.
Maesn handles all of the above. One unified API — no token management, no lifecycle edge cases, no dual-API routing, no module detection to build yourself.
E-conomic Authentication Requires Two Separate Tokens Per Request
Most modern accounting APIs use OAuth 2.0 with a standard authorization code flow, resulting in a single access token per tenant. e-conomic works differently. The API uses a proprietary token model with two distinct header values that must be present on every request:
X-AppSecretToken — this identifies your application globally. It is your app's secret credential and is set once per developer.
X-AgreementGrantToken — this identifies the specific customer agreement granting your app access to their e-conomic data. Every one of your customers has a different value here.
The flow to obtain the X-AgreementGrantToken goes through an installation URL that your customer must visit. After completing the authorization on e-conomic's side, the grant token is returned to your system. There is no token expiry and no refresh mechanism — the token is long-lived, but managing storage, rotation in case of revocation, and the onboarding UX is entirely your responsibility. For a multi-tenant SaaS product, this means building custom per-tenant token storage, a bespoke onboarding flow for every customer, and handling re-authorization if a customer revokes access.
How Maesn simplifies this: With Maesn, you register your e-conomic app once by providing the AppPublicToken and AppSecretToken. From that point, Maesn handles the entire connection flow in the backend. For you and your users, connecting an e-conomic account works like a standard OAuth flow - a single, consistent experience regardless of which accounting system is behind it. No custom token storage, no manual grant token management, no edge cases to handle per tenant.
Booked Invoices in e-conomic Are Immutable and PATCH Does Not Exist
In e-conomic, invoices exist in two structurally separate collections with different endpoints and different rules:
POST /invoices/drafts — creates a draft invoice that can be read and updated
POST /invoices/booked — books an existing draft, transitioning it to a final, legally relevant state
Once an invoice is booked, its core fields cannot be changed. If a correction is needed, you must issue a credit note against the booked invoice. This is standard accounting practice, but it has a direct consequence for integration architecture: your sync logic must be lifecycle-aware. Attempting a PUT on a booked invoice with updated line items will result in a validation error, not a silent no-op.
An additional constraint: e-conomic's REST API does not support PATCH. Updates are always done via PUT, and PUT expects the full document. If you are used to sending partial updates, you need to fetch the current state of the object first, merge your changes, and then send the complete updated document back.
How Maesn simplifies this: Maesn's documentation and integration layer clearly guides you on the required fields and the correct sequence for invoice creation and booking in e-conomic. You work with a unified endpoint model; the lifecycle handling and document-structure requirements for e-conomic are abstracted behind Maesn's common data model, so you do not need to engineer separate code paths for draft versus booked state management.
Visma e-conomic Has Two Active APIs With Different Pagination Limits and Coverage
When you start exploring the e-conomic developer ecosystem, you will encounter two distinct APIs that are both actively used — plus a third, the SOAP API, which reached end-of-life on December 31, 2023 and should not be used for new integrations (Maesn does not support it). The two relevant APIs are:
REST API (restapi.e-conomic.com): The well-established API that covers core entities as customers, invoices, products, accounts, journals, and more. Pagination returns up to 1,000 items per page and is navigated through nextPage links included in collection responses.
OpenAPI (apis.e-conomic.com): The newer API that uses cursor-based pagination for large collections. A critical constraint here is that classic pagination on this API is capped at 10,000 items total. Any data beyond that threshold is silently excluded if you rely on page-based traversal. For accounts or customers with large datasets, this is a serious correctness issue if not handled explicitly.
Certain functionality is only available in one of the two APIs. As an integrator, you need to decide upfront which API covers your use cases, whether you need to combine both, and how to handle the pagination differences consistently.
How Maesn simplifies this: Maesn supports both APIs and handles the mapping between them under the hood. You call a single unified endpoint, Maesn routes the request to the correct e-conomic API surface, handles pagination normalization, and ensures your data retrieval is complete regardless of collection size.
Creating Objects via e-conomic API Integration Requires Pre-Fetched Tenant-Specific References
You cannot create an invoice or a customer in e-conomic by sending self-contained data. The API requires resolved references for a set of tenant-specific objects that must be fetched first:
layout - every invoice requires a reference to a valid layout configured in the customer's e-conomic account
paymentTerms - required on invoices and customers, and defined per agreement
vatZone - determines how VAT is applied; the available zones depend on the customer's country and agreement settings
currency - must match a currency that exists in the agreement
accounts - for bookkeeping entries, account numbers must match the chart of accounts in the specific agreement
If any of these references are missing or invalid, the API returns a structured 400 error with per-property error annotations, which is helpful for debugging but means the entire request fails and must be retried after correction.
This reference resolution layer is not optional — it is structurally required. For a multi-tenant product, it means per-tenant onboarding logic where the customer or your system maps your internal data model to their e-conomic configuration.
How Maesn simplifies this: Maesn guides you clearly through which references are required for each operation on e-conomic. The onboarding configuration handled during the Maesn connection flow captures the relevant mappings for your customers, so your integration code does not have to resolve tenant-specific IDs on every request. The Maesn documentation specifies exactly what needs to be configured versus what is abstracted automatically.
Module-Based Access Control in e-conomic Can Cause Unexpected API Errors
e-conomic extends its core functionality through a module system. Modules such as Projects, Inventory, Subscriptions, Scanning, and Dimensions (departments) are optional add-ons that customers must have enabled in their agreement. If a module is not active for a specific customer, the related API endpoints return errors rather than empty results — meaning your integration can break for specific customers even if your code is correct.
For example, calling GET /projects for a customer who does not have the Projects module enabled will return an error response, not an empty collection. Similarly, accessing product.inventory in the REST API only works if the Inventory module is active. This makes it essential to check which modules are available for each tenant during onboarding, and to build your integration logic accordingly.
How Maesn simplifies this: Maesn's integration with e-conomic handles capability detection at the tenant level. If a particular endpoint or feature is unavailable for a specific customer due to module configuration, Maesn provides clear, actionable feedback rather than propagating raw API errors. We also provide guidance to you as our customer by clearly highlighting which modules are required for specific endpoints, so you can incorporate this into your integration helpdesk pages. You can focus on your use case logic without building custom module-availability checks per tenant.
Visma e-conomic Uses a Journal/Daybook Model for Bookings That Is Standard in Danish Accounting
In Danish accounting practice, financial entries are not written directly to ledger accounts. Instead, they are first recorded in a Daybook — known in Danish as Kassekladde — which serves as a staging area for bookings before they are formally posted. e-conomic reflects this model in its API: the Journal (Daybook) endpoints are the correct mechanism for creating bookkeeping entries.
For software teams coming from international accounting systems, this can be unexpected. If your product creates expense entries, payment registrations, or manual bookings, you need to understand the Daybook flow rather than attempting to write directly to accounts. The e-conomic REST API supports this via the /journals and /journals/entries endpoints, with specific rules for entry types, debit/credit balancing, and account assignment.
How Maesn simplifies this: Based on the agreement configuration captured during the authentication setup, Maesn executes the appropriate booking operations for your customer's account type. You do not need to detect or handle differences in booking behavior per tenant — Maesn routes and executes correctly based on the configuration context.
e-conomic Market: Getting Listed as a Partner Requires Meeting Formal Requirements
The e-conomic App Market is the in-product marketplace where customers discover and install integrations. Getting listed there provides visibility and trust for your product, but it requires formal approval from Visma e-conomic. Requirements include having:
an active customer base using your integration
a clearly defined target audience
multilingual support in your app
marketing materials
a signed partner agreement
If you are planning to distribute your product through the e-conomic marketplace, factoring in these requirements early in your go-to-market planning is important.
How Maesn supports this: Maesn helps you navigate the right path and supports you during the partner process. If you have questions before starting, reach out to the Maesn team early. If you are already a Maesn customer, speak directly with your dedicated contact.
Why Teams Use Maesn for Visma e-conomic API Integration
Building a direct e-conomic API integration with means handling a proprietary two-token auth model, lifecycle-aware invoice sync, dual-API routing, module capability detection, and the Danish Daybook booking pattern — all while keeping your codebase clean and extensible.
Maesn abstracts this entire surface into a single unified API. You integrate once to Maesn and your product automatically works with e-conomic and every other accounting system in the Maesn portfolio, without system-specific branches in your code.
Check the Maesn documentation for Visma e-conomic or talk to the Maesn team to get started.
