We build custom integrations between Sage and the other systems your business runs on, such as Stripe, an online shop, a CRM or a client portal, and the first thing that shapes the work is which Sage product you have.
What This Is
“Sage” covers several different products, and they don’t share an API. A firm on Sage 200 Professional, a firm on Sage 50 Accounts and a group on Sage X3 are asking for three different pieces of engineering, even when the sentence they use is the same: “we need our orders to go into Sage.”
The work itself is familiar. Web orders become Sage 200 sales orders without anyone re-keying them. Account status and outstanding balances show up in the CRM, so sales can see an account is on stop before they promise a delivery. Card payments taken through Stripe are posted against the right invoice. Clients log into a portal and see their own invoices and statements, read from Sage rather than copied out of it every month.
What we deliver is the software that does this reliably: a service layer that talks to Sage, a queue that retries when Sage or the other system is unavailable, and a log your finance team can read when they want to know why a record didn’t arrive.
Which Sage You Run Decides the Route
Sage projects most often slip on this, so it’s worth setting out. The details below are taken from Sage’s own developer documentation.
- Sage 200 Professional and Sage 200 Standard. Sage 200 has a RESTful API that reads and modifies customers, suppliers, products, sales and purchase orders, nominal accounts and more, using OAuth 2.0. The endpoints differ slightly between the two editions. On Professional, your Sage 200 support provider has to enable and configure the API, and every user the integration acts for needs a Sage ID. On Standard the API is on by default, but user access and Sage IDs still have to be set up. In practice this means the first week of a Sage 200 project involves your Sage business partner, and we plan around their diary rather than discovering the dependency halfway through.
- Sage 50 Accounts. Sage 50 has no web API on Sage’s developer portal. Third-party software connects through Sage Data Objects, a toolkit that is installed alongside Sage 50 and is licensed through Sage’s UK developer programme. So a Sage 50 integration needs a small component running on the machine or server that holds your accounts data, passing records to and from the cloud side. It works, but it has more moving parts than the cloud APIs, and sometimes the more useful conversation is whether the integration should wait for a move to a different edition.
- Sage X3. X3 offers REST, SOAP and GraphQL APIs, plus import and export templates for bulk data, and it runs multi-company and multi-currency across cloud, hosted and on-premises installs. We pick the interface per job: an API for records that need to move as they happen, templates for a large overnight load.
- Sage Intacct. Intacct is integrated through its REST API, which Sage updates on a regular release cycle, so we check the current release notes before building against it.
- Sage Accounting (formerly Business Cloud). The small-business cloud product, with its own API. Our page on how to connect Stripe to Sage covers that pairing in detail.
Two firms can both say “Sage 200” and still need different builds, depending on whether the install is on-premises, hosted by a partner or on Sage’s cloud. We confirm the edition, the version and where it runs before we estimate anything.
When You Need This
The trigger is usually one person spending part of every day moving data into or out of Sage. Somebody prints web orders and keys them into Sage 200 each morning. Somebody exports a customer list from Sage to update the CRM every Friday, and by Tuesday it’s out of date. A credit controller checks Stripe and Sage side by side to work out which invoices are paid.
The other trigger is growth. Keying in twenty orders a day is tolerable, but at two hundred the backlog starts affecting dispatch and month-end, and adding another person to type faster doesn’t fix it.
How We Work
We start with a short discovery: which Sage product and version you run, where it’s hosted, who your Sage partner is, and which records need to move in which direction. Then we agree which system owns each record. Sage stays the book of record for anything financial, and the other systems read from it or hand it clean data to post.
The build is a server-side integration with the same service-layer pattern we use for our Xero API integration work: authentication and token refresh handled centrally, requests queued, failures retried and logged so that a missed record can be replayed rather than re-typed. We test against a copy of your company data before anything touches the live ledger.
After go-live the integration is supported through our dashboard, where each change request is ticketed, the time spent on it is logged, and you can see both. When a Sage upgrade or a change in another system affects the integration, you raise it once and it gets worked. It doesn’t depend on someone remembering an email.
This isn’t the right route if a marketplace connector already does exactly what you need between Sage and one other product. Use the connector. We’re the better fit when the flow involves your own rules, more than two systems, or a portal your clients use.
What You Get
- An integration between your Sage edition and the systems you name, built on the interface Sage supports for that edition
- A written data map showing which record moves where, in which direction, and which system owns it
- Queued, retried processing, with a readable log of every record sent to or received from Sage
- A replay route for failed records, so nothing has to be keyed in by hand after an outage
- Testing against a copy of your company data before the live switch-over
- Ongoing support through a ticketed, time-logged process
Technologies We Use
The Sage 200 REST API with OAuth 2.0 and Sage ID users, the Sage X3 GraphQL, REST and SOAP interfaces, the Sage Intacct REST API, and Sage Data Objects for Sage 50. The integration layer is typically Laravel with queued workers, connecting to whatever sits on the other side, whether that’s Stripe, Shopify or WooCommerce, a CRM, or a portal we build. It sits within our wider API integrations practice, and the full API integrations overview lists the other platforms we connect.
Related Systems
Sage integrations often feed a client portal that shows invoices and statements, an order pipeline from a web shop, or a reporting dashboard that combines ledger figures with operational data. How these projects are scoped and costed is set out on our API integration pricing page.
Tell Us Which Sage You Run
Send us the Sage product and version you’re on, where it’s hosted, and the one flow that costs your team the most time each week. We’ll come back with the route your edition supports, what your Sage partner needs to switch on, and how we’d build it. Start the conversation here.
