The Sage Intacct REST API and XML API: How Velixo Reads Both

Sage Intacct runs your financials end to end, and it offers two ways to move data in and out. The XML API has been around for years and runs most of the integrations finance teams already depend on. The Sage Intacct REST API is newer, and Sage now ships every new object and feature through it. If you build reports on top of Intacct, the gap between the two decides what data you can reach and how cleanly you can work with it. Velixo reads both from the same workbook, so the choice between them stops being something you have to solve up front.

Two APIs into the same platform

Both APIs read and write the same company. They differ in how they’re built. The XML API speaks in structured XML documents and authenticates with Web Services credentials. The REST API uses standard HTTP verbs, JSON, and OAuth. New objects and features arrive in REST. Each quarterly release adds them there, and Sage publishes an XML-to-REST object map to point integrations across. The XML API stays in place. Its object-specific functions are labeled legacy and won’t be enhanced, and a handful of tasks still run through them as the only option.

What the Sage Intacct REST API changes about updates

The update model is where the two APIs feel most different in daily work. In the XML API, a generic update to a transaction treats the line set as a complete replacement. Change one field on one journal entry line and you resend every line on that entry. Leave a line out of the payload and Intacct removes it. Journal entries make this sharper, since they have no legacy update function at all, so the whole entry goes back every time you touch it.

The REST API gives each line its own key and its own endpoint. You can PATCH a single bill line, change one field, and leave everything around it in place. Omitting a line keeps it. Removing a line takes an explicit delete instruction. For allocation-heavy entries and high line counts, that’s the difference between a targeted edit and rebuilding the whole record.

Where the XML API still carries the load

REST now covers nearly all of the standard application objects. Sage’s object map shows equivalents across the general ledger, payables, receivables, order entry, inventory, and projects. Two things keep the XML API in active use. Sage documents that the object-specific legacy functions won’t be enhanced, and that in some cases they are the only functions available to complete a task. And the object map covers the financial and operational modules without listing Platform Services constructs, so defining custom objects and building Smart Rules and Smart Events still runs through the XML and Platform Services layer. A team that codes its own integration keeps an XML path next to the REST one to cover everything.

Objects only the Sage Intacct REST API exposes

Because new development ships through REST, several objects exist there and nowhere else. Fixed asset management is REST from end to end. Construction WIP forecasting, including WIP periods and WIP projects, lives in REST. Tax entries on bills, invoices, and journal entries are addressable as their own records in REST, where the XML API keeps them inside the parent transaction. If your reporting depends on any of these, REST is the route to the data.

How Velixo reads the Sage Intacct REST API

Velixo reads both APIs from inside Excel, and the function name tells you which one you’re using. The SI.QUERY family talks to the XML API. The SI.XQUERY family talks to the REST API. The X marks the REST path, and it’s how you reach the objects Sage only exposes there. You don’t commit to an API at the start of a project and live with it. You pick the function that matches the object, formula by formula.

SI.XQUERY pulls a REST object into a spill range or an Excel table. You point it at an object like construction-forecasting/wip-period, add a filter, and pick your columns. SI.XOBJECTDEFINITION returns the fields, data types, required flags, and valid values for that object, so you work from real field names instead of guessing. SI.XEXPANDOBJECTRANGE lists the objects you can query. SI.XQUERYLOOKUP returns a single field for one record when that’s all you need. SI.XQUERYFILTER builds the filter expression. Since the 2025.7 release, SI.XQUERY also supports SUM, COUNT, MIN, MAX, and AVERAGE, so you can group and total inside the query.

A pull of posted WIP periods ending in the first quarter of 2025 reads like this:

=SI.XQUERY(
  "Sage",
  "construction-forecasting/wip-period",
  "periodEndDate >= '2025-01-01' and periodEndDate <= '2025-03-31' and state = 'posted'",
  "key, periodName, state, periodEndDate"
)

The result refreshes with the workbook, so the numbers stay current as the period rolls forward.

One workbook, both APIs, no rebuild

Sage releases its new objects through REST. A team that builds its own integration against one API takes on rework when it needs an object that only the other exposes. In Velixo, both APIs sit behind Excel formulas. Established reports keep running on the SI.QUERY functions. REST-only objects become reachable through SI.XQUERY as soon as they’re in the REST API, with no migration project and no code to maintain. You keep pace with Sage’s roadmap by writing a formula.

That’s the strategic part. The two-API reality costs integration teams real time and real maintenance. For a finance team working in Excel, it becomes a column you add when you need it.

Put it to work in your next report

See it against your own data. Point SI.XQUERY at a REST-only object like fixed asset management or WIP forecasting and pull it into a report that refreshes with the workbook, while your existing SI.QUERY reports keep running. Request a demo to walk through it with a Velixo expert, or start from the Sage Intacct sample reports and the function reference in the Velixo help center.