Sage Intacct runs both a newer REST API and an older XML-based Web Services API, both documented through Sage's developer portal. Getting programmatic access means enabling Web Services on your Intacct company and obtaining a sender ID, not just signing up for a developer account somewhere separate. Once that's set up, the API genuinely supports custom integration work well, which is exactly why we build directly against it rather than routing everything through a generic connector.
Intacct's API access starts with enabling the Web Services feature on your company and registering for a sender ID, Intacct's term for the credential that identifies the application calling in. This is a specific, documented step, not an assumption; without it, API calls simply won't authenticate, no matter how correct the request itself is.
The REST API is the newer, more modern interface, following standard REST conventions and generally easier to build against for new integrations. The older XML-based Web Services API (sometimes called the "xmlgw" API in Intacct's own documentation and community) still works and still runs a lot of existing integrations, particularly ones built before the REST API existed.
Documentation for both lives on Sage's developer portal, covering authentication, object structures, and the specific fields each Intacct module exposes. It's thorough enough to build against confidently, which matters given how much financial logic (dimensions, revenue recognition, multi-entity structures) sits underneath even a simple-looking transaction.
A fair number of people hit a wall before they even get to writing integration logic, because the sender ID and Web Services enablement step isn't obvious if you're expecting a typical "sign up and get an API key" developer experience. It's a different model, closer to how older enterprise financial systems handle API access generally, and skipping it is the single most common reason a first API call fails.
Past that setup step, the real work is the same as any serious integration: correctly handling Intacct's dimension structure (entity, department, class, location) so the data you push through lands tagged the way your reporting actually needs it, not just technically valid but practically useless.
We build the integration that creates contracts and billing schedules in Sage Intacct from a closed CRM deal, with entity, department, and class tags set correctly from the start rather than fixed up later.
We pull exactly the data a leadership dashboard or external report needs directly from Sage Intacct's API, instead of exporting and reformatting a standard report every reporting period.
Tell us what you're trying to build and we'll get the access configured correctly before writing a line of integration logic.
Tell us what you're trying to move in or out of Sage Intacct, and we'll scope the real work, API access setup included. Sage Intacct happens to have one of the stronger APIs we build against, but the same approach applies to any system in your stack that still needs a custom connection.
Let's talk →It's the credential that identifies an application calling into Intacct's API, required alongside enabling the Web Services feature on your company before any API calls will authenticate successfully.
The REST API is the newer, modern interface following standard REST conventions. The Web Services API (sometimes called xmlgw) is the older, XML-based interface that predates it and still runs a lot of existing integrations built before REST was available.
You need Web Services enabled on your company and a registered sender ID, which functions similarly to a developer license requirement. It's a specific setup step, not an assumption, and skipping it is the most common reason a first API call fails to authenticate.
Yes, through Sage's developer portal, covering both the REST and Web Services APIs, authentication, and the object structures and fields each module exposes.
Technically yes, since the API is documented and accessible once Web Services is enabled. In practice, many businesses still involve their implementation partner for anything touching financial logic, given how specific Intacct's dimension and revenue recognition rules get.