Most growing companies already have the systems they need: an accounting software, an e-commerce platform, a CRM and perhaps an inventory or payroll system. The problem is that they don't talk to each other. Someone copies orders manually, the customer register exists in three versions and the invoices are entered by hand. An integration solves this by letting the systems exchange data automatically – but it's a real software project, not a button you turn on.
What an integration project actually means
An integration connects two or more systems so that data flows between them without manual work. It sounds simple, but the core of the work is rarely the technology itself – it's agreeing on what datameans. What is a customer in e-commerce compared to a customer in accounting? When is an order considered ready enough to become an invoice? Which system owns the truth about an item's price?
A typical project has four phases: mapping of flows and data models, selection of integration patterns, building and testing against the suppliers' sandbox environments, and operation with monitoring. The first phase is often the most important and most underestimated. Plotting exactly which fields should be mapped between systems—and what happens when they don't match—determines whether the project will be stable or a source of constant bugs.
APIs: the foundation of all integration
An API (Application Programming Interface) is the system's door to the outside. Most modern business systems offer a REST API where you retrieve and send data over HTTP. For Swedish companies, Fortnox and Visma are the heavy players.
Fortnight
Fortnox offers a REST API (version 3) and uses the OAuth2 Authorization Code Flow for authentication. You register your integration in the Fortnox developer portal and receive a Client ID and Client Secret. The customer himself approves which authorizations (scopes) your integration should have. It's worth noting that the authorization code you get in the feed is only valid for ten minutes and can only be used once to retrieve the access token – a common rookie mistake is not handling token renewal robustly.
Visma - nowadays Spiris
Here's a name confusion to be aware of in 2026: Visma Spcs has changed its name toSpiris, and the Swedish product that was called Visma eEkonomi is now calledAccounting & Billing. The important thing for you who integrates: The API is unchanged. Visma eAccounting, eEconomics, Spiris and Accounting & Billing points to the same API oneaccountingapi.vismaonline.com. If you already have an integration, you do not need to change any code - but documentation and agreement texts may look different depending on when they were written.
The Visma API is REST-based, uses OAuth 2.0 with scopes and a sandbox with test companies. The access token is valid for 60 minutes, making proper management of the refresh token mandatory for every connected customer. The API has built-in support for Swedish specialties such as ROT/RUT invoices and the BAS chart of accounts.
Webhooks: when you don't want to ask all the time
There are two ways to keep systems in sync. The first ispolling- you ask the API at regular intervals: "are there any new orders?". It's simple and works against any API, but introduces delays and a lot of unnecessary calls. The second iswebhooks– the system calls you when something happens. When an order is created, the e-commerce sends an HTTP call to a URL you specify, almost in real time.
Fortnox supports webhooks for certain objects, especially customers and invoices. For many other objects – such as supplier invoices, vouchers and payments – there is no native webhook support, and then you have to fall back on polling. It's a concrete constraint to design around, not a detail to discover in operation.
Webhooks are unreliable – and that's the point
The single most important insight about webhooks: no provider guarantees that an event will be delivered exactly once. All serious suppliers runat least one-time delivery(at-least-once). This means that sooner or later your recipient will receive the same event twice – and have to deal with it without creating duplicate invoices or duplicate mailings.
The solution is calledidempotency: the same input should give the same result even if it comes twice. In practice, you calculate a unique key for each event, check if you've already processed it, and only apply the change if it's new. Idempotence is not a bonus feature – it is the backbone of every production-ready webhook integration.
Equally important isretries. If your endpoint responds with an error code or doesn't respond at all, the provider tries again with exponential backoff – often over hours. If you do not respond after all attempts, the event may be lost completely. Therefore, the recommended pattern is 2026 onehybrid: webhooks as the primary real-time channel, supplemented by periodic polling as a safety net to catch events missed by webhooks in the event of operational disruptions.
Common integration patterns
Order-to-invoice:an order in e-commerce (e.g. Shopify or WooCommerce) automatically becomes an invoice or a voucher in Fortnox or Visma. The most common and most value-creating flow.
Customer and article sync:customers and products are kept in sync between CRM, e-commerce and accounting so that the same customer does not exist in five versions.
Inventory balance:balances are updated between inventory and e-commerce systems to avoid overselling.
Payment Matching:payments from the payment provider are matched against invoices and posted.
Most projects can be built either as a custom integration or via an iPaaS (integration platform as a service) platform that handles authentication and queuing for you. Tailor-made provides full control and suits complex, business-critical flows; a platform is faster for standardized connections but costs in flexibility and ongoing fees.
Data quality determines whether it lasts
An integration is never better than the data it moves. Most breakdowns are not about code, but about data: duplicates, organization numbers in the wrong format, currencies that don't match, VAT rates that are interpreted differently. Before connecting the systems, you need to decide which system is whichthe source of truthfor each data type – and what should happen when the data does not validate.
Build in three things from the start:validationthat stops broken data at the door,loggingso that every event can be traced, andalarmwhen something gets stuck. A silent integration that has stopped working is more dangerous than no integration at all, because you stop double-checking manually and discover the error only when the financial statements are not correct.
What it costs - and what the price depends on
There is no standard price for an integration, as the range is huge. The price is governed by how many systems are connected, how well their APIs support what you want to do, the data volumes, how much data washing is required, and whether you need realtime via webhooks or can handle nightly sync. A simple order-to-invoice against a well-documented API is a completely different project than a sync between five systems with dirty historical data.
If you want an estimate for your particular flow, it is easiest to describe the systems and the needsthe quote calculator- then you get a picture of the scope without guesswork.
ZORC builds the integration that lasts
We have connected Fortnox, Visma/Spiris, e-commerce and CRM for companies tired of manual duplication - with idempotence, monitoring and hybrid between webhooks and polling so that it actually works in operation, not just in demo. Tell us what you want to connect viacontact, and we will find the right approach for your system.
