Skip to main content

Data Mart API - 2026-08-31

Data Mart Team
Visma Net ERP Data Mart

New Endpoints​

Both are marked EXPERIMENTAL: they may change or be removed without notice, and they are not yet recommended for production integrations. They are published now so you can evaluate them and give feedback on the pagination contract before it is fixed.

  • generalLedgerBalancesForwardByGroupV2 - Forward-period expansion paginated by group, replacing generalLedgerBalancesForwardByGroup. Same arguments and same response shape; the difference is that page cost no longer grows with the size of your company's dataset.
  • generalLedgerBalancesByPeriodV2 - The latest balance at or before a given financial period, one row per ledgerId / branchId / accountId / subaccountId group, replacing generalLedgerBalancesByPeriod.

Improvements​

  • Full fetches of general ledger balances no longer slow down as the company grows. Previously the time to serve a page was driven by how much data remained after your cursor rather than by how many rows the page returned, so each page of a large company got progressively more expensive and a complete fetch grew quadratically with dataset size. On the largest datasets this meant a full fetch measured in tens of hours. The V2 endpoints serve each page at a cost proportional to the rows it returns, so throughput stays roughly constant from the first page to the last.
  • Larger pages on generalLedgerBalancesForwardByGroupV2. pageSize now accepts up to 1000 groups, up from 100 on the endpoint it replaces. The previous limit existed only to contain the per-page cost described above. Fewer, larger pages are now cheaper than many small ones.
  • Parallel ledgers are reported separately by generalLedgerBalancesByPeriodV2. See Breaking Changes for what this means if you are migrating.

Deprecations​

  • generalLedgerBalancesForwardByGroup - Superseded by generalLedgerBalancesForwardByGroupV2. This version applies its pagination cursor after grouping, so every page reprocesses the whole remainder of your dataset. Both endpoints remain available.
  • generalLedgerBalancesByPeriod - Superseded by generalLedgerBalancesByPeriodV2. This version paginates on the document id, which forces the whole balance set to be regrouped on every page, and it omits ledgerId from its grouping. Both endpoints remain available.

Breaking Changes​

  • generalLedgerBalancesForwardExpanded has been removed. This endpoint was marked experimental and had no recorded usage. Use generalLedgerBalancesForwardByGroupV2 instead, which paginates by group count rather than by an approximate source-document budget.

  • Pagination cursors are not interchangeable between an endpoint and its V2 replacement. The V2 endpoints iterate groups in a different order, so a lastGroupKey obtained from generalLedgerBalancesForwardByGroup cannot be used to resume against generalLedgerBalancesForwardByGroupV2. V2 cursors are prefixed with v2: and a mismatched cursor is rejected with an argument error rather than silently resuming from the wrong position. When you migrate, start the crawl from the first page.

  • generalLedgerBalancesByPeriodV2 returns more rows than generalLedgerBalancesByPeriod for companies using multiple ledgers. The previous endpoint grouped by account, subaccount and branch only. Where a company keeps parallel ledgers such as Actual, Report and Statistical, those were collapsed into a single row per account/subaccount/branch, and which ledger's figures survived depended on which one happened to hold the most recent period. generalLedgerBalancesByPeriodV2 includes ledgerId in the grouping, so each ledger is returned as its own row and you can tell them apart. On a company with four ledgers this raised the row count from 1,849 to 2,792. If your integration assumed one row per account/subaccount/branch, filter on the ledgerId you need.

  • generalLedgerBalancesByPeriodV2 paginates on lastGroupKey instead of lastId. The replacement takes a lastGroupKey argument and returns a page object carrying items, lastGroupKey and hasMore, in place of a bare list paginated by lastId.

  • The default pageSize changes on both replacements, so a request that omits it returns a different number of rows. pageSize counts groups on the V2 endpoints, not documents, and defaults to 1000 on both. Migrating from generalLedgerBalancesByPeriod that is a decrease (its default is 5000 documents); migrating from generalLedgerBalancesForwardByGroup it is an increase (its default is 100 groups). Send an explicit pageSize if your integration depends on the page size rather than following hasMore.