How to integrate with the e-conomic API

e-conomic is the accounting system behind more than 250,000 customers, according to e-conomic.com, and it has been part of Visma since HgCapital sold the core Scandinavian business in an all-share deal in May 2015. For a SaaS team entering Denmark, it is a likely first local ledger after QuickBooks and Xero. The e-conomic API is free to use and doesn't use OAuth, and it changed a lot in 2026: new API terms in June, a webhooks API announced in May, and a token-bucket rate limit that started rolling out in December 2025.

Two e-conomic APIs, one set of tokens

e-conomic runs two REST-style APIs side by side. The older one at restapi.e-conomic.com is labelled "Legacy REST" in the developer documentation. It is in feature freeze, and e-conomic's guidance on choosing an API says "Integrations should be OpenAPI-first", meaning the versioned APIs at apis.e-conomic.com. The SOAP API was deprecated from 2023 and is no longer reachable.

Most integrations end up using both. Several things exist only in REST today: GET /self, booking and sending invoices, VAT accounts and VAT zones, and supplier records themselves (the Suppliers OpenAPI covers only contacts and groups). The OpenAPI side has the newer resources, such as dimensions, booked entries, journal booking and the webhooks API. Both accept the same headers, so one connection serves both.

OpenAPI paths carry their version, for example /journalsapi/v16.0.1/, and e-conomic supports the previous major version for up to 12 months after a new one ships. REST has no versioning: the root always serves the latest version.

Authentication with grant tokens

e-conomic doesn't use OAuth. Every request carries two tokens in headers, per the REST docs:

curl https://restapi.e-conomic.com/self \
  -H "X-AppSecretToken: <your app secret token>" \
  -H "X-AgreementGrantToken: <the customer's grant token>" \
  -H "Content-Type: application/json"

The X-AppSecretToken identifies your app. You get it by signing up for a free developer agreement, creating an app and choosing its role. e-conomic shows the secret once, and resetting it issues a new one. The X-AgreementGrantToken identifies one customer's grant. Your app has an Installation URL; the customer opens it while logged in to their e-conomic company and approves access. If you register a redirect URL, e-conomic appends the token as token=xxx to the redirect, per its connect guide. Without one, the token is shown on screen for the user to copy. Accountants who manage several companies click "Administer" on the right agreement first, and each company produces its own grant token.

Two details catch teams out. The app's role is set when you create it. e-conomic's permissions page lists four roles, from SuperUser down to Project employee, and an app created with the Sales role can't reach journals. The webhooks API requires SuperUser. Grant tokens also have no expiry, according to e-conomic's 2018 post on tokens, the latest statement on record; the customer can revoke one under Settings, and your next call returns 401.

App registration and the 2026 API terms

Creating a developer agreement and an app costs nothing. Production access now comes with conditions. The Developer Terms for e-conomic API, updated 12 June 2026, grant production access only to businesses with a valid CVR number or a foreign equivalent, and the developer must verify their identity with a national electronic ID or a passport. A new production app gets an initial quota of 20 installations. At 20, new installations are blocked until e-conomic verifies the app, while existing ones keep working.

The terms also restrict what you do with the data. Partners may not build "a parallel database" from e-conomic data; temporary caching is allowed, with dynamic invalidation instead of scheduled bulk refreshes. API data must not be used to train or fine-tune AI models. Misuse carries liquidated damages of at least DKK 100,000 per violation, plus DKK 10,000 a day until it stops. If your product design depends on a nightly copy of the customer's ledger, read section 6 of the terms before you build it.

Listing in e-conomic's Apps section is a separate step with its own review: a live test meeting where you demo onboarding and the data flow. A listing in the in-app marketplace goes through your developer agreement. e-conomic's app partner FAQ says scheduling it takes roughly one to two weeks.

Checking the agreement with GET /self

The grant token doesn't tell you which company granted it. Call GET /self first, as e-conomic recommends. The response carries the agreementNumber, the company's CVR in companyIdentificationNumber, the app's roles, and agreementType.subscriptionPlanLevel.

That last field matters for writes. Agreements on the Basis plan support only read operations through the API, and a write returns 403 with "The license is read-only." Plus and higher plans get full create, read, update and delete. Store the plan level at onboarding and tell Basis customers before they try to sync anything into e-conomic.

Reading data

REST collections return 20 items by default and up to 1,000 with pagesize, paged with skippages. Filters use a dollar syntax, documented under filtering:

GET https://restapi.e-conomic.com/customers?filter=name$eq:Joe$and:city$like:*port&pagesize=100

The operators include $eq:, $gt:, $like: and $in: (numeric properties only, up to 200 values), and string filters are case-insensitive. Only properties marked filterable in the schema accept a filter; anything else returns 400.

The OpenAPI side offers cursor pagination, usually 1,000 items per page, and an older /paged endpoint capped at 100 per page and 10,000 items in total. Use the cursor.

Incremental sync works per resource, not globally. REST customers, draft invoices, orders, quotes and products filter on lastUpdated. Booked invoices don't, so page them by bookedInvoiceNumber or date instead. For the general ledger, e-conomic recommends filtering booked entries on entryNumber$gt: the highest number from your last sync; since September 2025, reopening a closed year books reverse entries instead of deleting them, which keeps that approach reliable.

Writing invoices and vouchers

Invoices go through two steps. POST /invoices/drafts creates a draft, which you can still edit. The required fields are currency, customer, date, layout, paymentTerms and a recipient with a name and VAT zone:

{
  "date": "2026-10-18",
  "currency": "DKK",
  "customer": { "customerNumber": 1 },
  "paymentTerms": { "paymentTermsNumber": 1 },
  "layout": { "layoutNumber": 21 },
  "recipient": {
    "name": "Example ApS",
    "vatZone": { "vatZoneNumber": 1 }
  },
  "lines": [
    { "product": { "productNumber": "1" }, "quantity": 2, "unitNetPrice": 450.00 }
  ]
}

Read the numbers for layouts, payment terms and VAT zones from /layouts, /payment-terms and /vat-zones on each agreement. Booking is a second call, POST /invoices/booked with {"draftInvoice": {"draftInvoiceNumber": 2}}, documented here. A booked invoice can't be edited. Credit notes aren't a separate resource; they are invoices with negative amounts. An optional sendBy sends the invoice on booking, by email or as an electronic invoice through NemHandel, where the invoice recipient's NemHandel type decides the route, with Peppol as one option.

The revenue account doesn't go on the invoice line. It comes from the product's product group, which can map a different sales account per VAT zone, per e-conomic's support article. If revenue lands on the wrong account, check the product group before your mapping.

Journal entries go into a journal (kassekladde) as vouchers. REST POST /journals/:journalNumber/vouchers takes an accounting year and entries grouped by type, such as financeVouchers, supplierInvoices and customerPayments. VAT is set by code on each entry, and the codes are agreement-specific: a Danish agreement typically has U25 for 25% output VAT and I25 for input VAT, but read /vat-accounts rather than hardcoding them. REST can't book a journal; the Journals OpenAPI can, with POST /journals/{journalNumber}/book. Writes also accept an Idempotency-Key header, and e-conomic replays the cached result for an hour.

Webhooks

Webhooks used to be set up by hand in the e-conomic interface. Since the announcement in May 2026, a webhooks API can manage them, with 20 event types such as INVOICE_BOOKED, CUSTOMER_UPDATED and JOURNAL_BOOKED. The API only returns webhooks your own app created.

The payload is a template you define, filled with merge fields such as [INVOICENO] or [OLDNUMBER] and [NEWNUMBER], so an event tells you which record changed and you fetch it afterwards. e-conomic documents no signature. You can send up to five custom headers to carry a shared secret. e-conomic listed its source IPs for allowlisting in a 2017 post, so confirm the current range with api@e-conomic.com before relying on it. Delivery is retried five times over about 26 minutes. If more than 250 requests to one URL fail within 24 hours, e-conomic disables the webhook and drops events until you re-enable it, per its webhook guide, which also recommends a nightly reconciliation.

Rate limits

Since December 2025, e-conomic meters calls with a token bucket for each app and agreement pair. Each call costs tokens by weight: e-conomic's rate limiting article puts GET /self at about 5 tokens and a booked invoice at about 13. Responses carry X-RateLimiting with the remaining and total tokens and X-CallCost for the call. Over budget, you get 429 with a Retry-After header. The published bucket sizes are examples, so read the headers instead of hardcoding a number. Repeated requests with a known idempotency key cost nothing.

Testing

Any GET works against e-conomic's demo agreement with demo as both tokens, which is enough to explore responses. It is read-only. For writes, e-conomic suggests a free 14-day trial company with demo data, which it will extend for testing on request. The terms mention a dedicated sandbox as upcoming, with no date. Check the trial's plan level with /self before testing writes, because a read-only plan returns 403.

Before you go live

The Danish Business Authority's register lists e-conomic as a registered digital bookkeeping system, and from 1 January 2027 registered systems must export SAF-T in version 2.1, per Erhvervsstyrelsen. The books of record live in e-conomic, which is one more reason to post transactions into it rather than keep a ledger of your own. The Nordic accounting fragmentation post shows how differently the neighbouring countries handle this, and the Visma portfolio post explains why Dinero, Visma's other Danish system, needs a separate integration.

Apideck supports e-conomic in beta through its Accounting API. The e-conomic connector covers customers, suppliers, invoices, credit notes, products, quotes and sales orders with create, read, update and delete (invoices, credit notes, quotes and orders are written as drafts, and booked invoices are read-only), plus read access to ledger accounts, tax rates and journals. It creates bills, bill payments and journal entries as unbooked vouchers. Each customer pastes their grant token once into Vault, and the data passes through without a stored copy, which fits e-conomic's terms. If Denmark is one market among several, the Accounting API gives you e-conomic and the other ledgers through one integration, so start with the e-conomic connector in a trial company and check your plan level first.