Most finance teams using Sage run into the same problem. The ERP has the General Ledger, the customers, the vendors, and the bills. But that data has to get to the CRM, the storefront, the reporting stack, or the expense tool. Sage API integration closes that gap, so information moves between accounting systems and third-party systems on its own instead of someone rekeying journal entries at month-end.
Sage Intacct, Sage X3, Sage 300, Sage 200, Sage 100, Sage 50, and Sage Accounting were each built in a different era on a different architecture and expose a different application programming interface. Some give you a modern REST API and OAuth 2.0. Others give you a COM library that must run on a Windows box next to the data.
This article details what each Sage product exposes in practice, then dives into Sage Intacct (the cloud-native product and the one that most new integration work targets), before discussing the limits and best practices that apply across all of them. And if you’re looking for a managed integration solution with many other benefits, we also answer how DCKAP can meet your needs.
Which Sage Product, Which API
Different Sage products use different integration methods, as each was built with its own architecture, data model, and communication standards. Here’s what each one actually gives you.
| Sage product | Programmatic interface | Authentication | Best suited for |
| Sage Intacct | REST API, generally available since 2025 R1, plus the legacy XML API; new objects ship on REST only | OAuth 2.0 with a client ID and secret | Real-time, cloud-to-cloud financial data synchronization |
| Sage X3 | Web API in the RESTful style, built on SData 2.0, plus SOAP for modules still on the classic interface | OAuth 2 the only option on Sage X3 Online; basic or certificate on-premises. | Complex mid-market and manufacturing workflows |
| Sage 300 | RESTful, OData-based Web API with JSON, alongside the older XAPI, COM, and .NET interfaces, plus an SDK for web screens | HTTP Basic | On-premises master-data sync on a Windows, IIS, and SQL Server stack |
| Sage 200 | RESTful API enabled by default in Standard, switched on manually in Professional | OAuth 2.0 authorization code via Sage ID, with X-Site and X-Company headers | UK and Ireland mid-market, where a user can complete consent |
| Sage 100 | No Sage-published REST API. The COM-based Business Objects Interface comes with activation. | Sage 100 user and company, in-process on Windows | Local connectors that write while respecting business rules |
| Sage 50 (UK) | Sage Data Objects read, create, edit, and delete against the local data path; the ODBC driver is read-only and unsupported. | Local data-path credentials; UK Sage Developer Programme membership required | On-premise connectors running where the data path is mounted |
| Sage 50 (US) | A separate product with its own downloadable SDK, currently 2026.0 edition | Local session, registered application | Windows desktop add-ons |
| Sage Accounting | REST API at v3.1, which unified the base URL across countries | OAuth 2.0: an optional X-Business header picks the business | Cloud-to-cloud small-business sync |
A Note on Regions
Sage Intacct 2026 R2 release notes include country-specific sections for Australia, Canada, France, Germany, South Africa, the UK, and the US. For a company in Germany, DATEV export, GoBD export, and UStVA submission using ELSTER are all within the same system that your integration reads from, so local financial reporting obligations are part of the mapping conversation.
Also look out for reuse of names: the Sage Business Cloud Accounting API in South Africa is a separate API with its own base URL. Authentication is via an API key as a query parameter. The limit is 5,000 requests per day per company.
Methods of Sage API Integration
Each requires a different mechanism, and the options depend on the product: a one-off report, a real-time order sync, and a nightly warehouse load.
REST & Web APIs:
It is the default for new development where available. With the 2025 R1 release, Sage Intacct’s REST API became generally available, and Intacct recommends client applications use it because that is where new objects and features ship.
Sage X3’s Web API is SData 2.0 based, a RESTful protocol specification published by Sage. Sage 300 is RESTful and OData-based with JSON. Sage 200 and Sage Accounting also provide REST. Sage 100 and Sage 50 have none, so a cloud-to-cloud pattern that works for Intacct simply does not transfer.
Legacy XML and SOAP Gateways:
Sage Intacct’s XML API is considered legacy, although Sage says it has no plans to retire the object-specific functions, and in some cases they are the only functions out there. Sage X3 continues to use SOAP for modules that are still using the classic interface and uses its Web API for the upgraded ones.
One practical catch on the Intacct side: the gateway also needs a Web Services sender ID that the target company has authorized, which is an admin task on the customer’s end rather than something you can arrange yourself.
Local COM libraries and SDKs:
Sage 100’s Business Objects Interface is automatically included when activated and gives developers access to Sage 100 programs through the Component Object Model. Sage 50 UK uses Sage Data Objects against the local data path, gated by Developer Programme membership.
Sage 50 US is a separate product with its own SDK. All three need something running on a Windows machine with the client components installed, so a cloud platform connects to them through an on-premises agent rather than a public endpoint. There is also no token to expire and no scope to narrow here, which turns the question of where those credentials sit into a data security decision.
ODBC and direct data access:
Sage 100 ships an ODBC driver through the SOTAMAS90 DSN, which is used by Microsoft Excel, Access, Crystal Reports, SQL Server DTS, and any ODBC-compliant application. On Sage 50, the driver is read-only and unsupported. Treat ODBC as extract-only. Writing directly to the tables of ERP systems bypasses the business logic those business processes depend on.
Event-based triggers:
Platform triggers automatically create input, output, update, validation, email, and Web Services calls on data changes to both standard and custom objects in Sage Intacct. The same is true on the Customization Services side with smart events, although Sage now directs existing users to triggers.
This mechanism allows real-time data synchronization without an external system polling on a schedule; where a product has no equivalent, scheduled polling is the fallback.
Bulk Extraction:
Sage Intacct’s Data Delivery Service can send large volumes to cloud storage for reporting and analytics across systems outside of Intacct. This can be done on a schedule or on demand, and you can choose to only send changed records. It’s not a free subscription, and it always pulls from the top level of a multi-entity company.
Import/export by files
The import service in Sage Intacct is validated and previewed before posting and will roll back if something is wrong. Sage 100 has a tool called Visual Integrator that handles both imports and exports. Sage 50 imports most records from CSV or Excel using a mapping wizard. The caveat is that an import cannot be undone. This is good for occasional loads and migrations, but bad for anything continuous.
The AI Gateway
What’s new in Intacct 2026 R2: AI application connectivity via the REST API and an MCP server currently available in Australia, Canada, Singapore, South Africa, the UK, and the US.
Integration Platforms
This approach is not a ninth method, but rather how most companies implement the other eight methods, particularly in a mixed environment where one connection uses OAuth over REST and the next relies on a COM library behind an agent.
DCKAP Integrator interfaces with Sage through REST, for more seamless, reliable data sharing, and plans a hybrid approach for the older products. It removes authentication, field mapping, retries, scheduling, and error alerts. Batch sync runs on a schedule. Dynamic sync uses webhooks so a website order hits the ERP in seconds.
Limits and Throughput
Sage Intacct has performance tiers. As Sage partner RKL eSolutions explains, Tier 1 is the default at 100,000 transactions per month; any query, readByQuery, create, update, or delete, and batched creates are counted individually; and query results are limited to 2,000 per call.
Concurrency is limited by company, and a large request can time out after 15 minutes, so Sage recommends queries under 1,000 records and data-changing calls under 100. Sage 200 pages at 500 records by default, with a maximum of 5,000.
Sage 300 supports one record per write request and indicates overload with a TooManyRequests error, not a published number. Sage 100 and Sage 50 have no hosted API at all to rate-limit; throughput is instead limited by COM session cost and user licensing.
Platforms justify their existence with throttling, and DCKAP Integrator has a sleep step that inserts pauses between actions to keep an integration within a target system’s per-minute request limits.
Best Practices for Sage API Integration
- Develop on the latest interface that the product offers. On Intacct, that means REST, since new objects ship nowhere else. No REST option? Then the choice is made for you.
- Integrate with a tightly scoped account, and revoke tokens on role changes. On Intacct, revoking a single token for a user and company revokes the other tokens.
- Filter and paginate everything. Intacct’s cap of 2,000 records per query and 100,000 transactions per month means disciplined reads of Sage data can be the difference between a clean monthly bill and an overage charge.
- Watch out for replace-on-write objects. All journal entries in Intacct are done through GLBATCH, where an update replaces every entry, and line items are normally owned by a header and updated through it.
- Manage dates/format yourself. Each Sage product has a similar quirk, as Intacct dates carry no timezone and ISO 8601 is unsupported. DCKAP Integrator’s mapping and modifier tools perform this kind of work at the field level by drag and drop.
- Log every step and flag failures. The costly failure mode is silent partial syncs, and the integration process should surface them. DCKAP Integrator uses detailed loggers, console logs, and rule-based email alerts.
Related read: Understanding Sage ERP Integration
DCKAP’s Integrator: ERP-First Integration For Sage
Sage doesn’t often run alone. For most companies in distribution and manufacturing, the ERP connects to eCommerce, a CRM, a PIM, and EDI simultaneously. And for organizations whose estate spans more than one Sage product, that means several different APIs and credential models to keep alive at once.
DCKAP is an ERP-first integration platform. The ERP remains at the core of the platform, with the rest of the tech stack connected to it, removing the back-and-forth manual data transfer. Pre-built connectors remove the need for manual coding; the drag-and-drop interface is still useful for the non-technical user, and the flow designer supports customization.
DCKAP also offers robust EDI management features, with the DCKAP team managing trading partner onboarding, mappings, and validations, and fully managing setup, monitoring, and maintenance so a distributor does not need an internal integration team.
That seamless integration includes order synchronization with stock levels managed in real time, financial data keeping the website and its customers in sync with the accounting platform, inventory reconciliation, real-time data synchronization of customer records between CRM and ERP, and EDI exchange with trading partners.
Conclusion
Sage API integration is not a single job. Sage Intacct, X3, and 200 have REST and OAuth 2.0. Sage 300 has REST with basic authentication. Sage 100 and Sage 50 have COM libraries that run right next to the data.
First, be sure about the product, version, and region, as that decision dictates everything downstream. Then the rules are the same everywhere: build on the most modern interface available, give the integration its own tightly scoped account, paginate, and know your ceiling before you hit it.
Want to explore how DCKAP can get Sage talking to the rest of your business systems? Schedule a chat with our integration experts to know more.
FAQs
Does every Sage product have a REST API?
No. Sage Intacct, Sage X3, Sage 200, and Sage Accounting all have REST APIs. Sage 300 has a RESTful Web API with basic authentication. Sage 100 has none; its route is the COM-based Business Objects Interface. Sage 50 uses Sage Data Objects in the UK, or a downloadable SDK in the US.
Which Sage products can run a fully unattended integration?
Sage Intacct supports OAuth 2.0 with the client credentials grant. Sage 200 cannot run unattended; the user must authenticate first and re-consent every 90 days. Sage 100 and Sage 50 have no token expiry at all but require a process running on a Windows machine next to the data.
