--- title: "How to Integrate with the Sage Intacct API: A Guide for B2B SaaS" slug: how-to-integrate-with-the-sage-intacct-api-a-guide-for-b2b-saas date: 2026-03-27 author: Roopendra Talekar categories: [Guides, Engineering, By Example] excerpt: "Sage Intacct requires two separate APIs, multi-layer auth, strict concurrency limits, and manual timezone handling. A technical guide covering the real challenges and build-vs-buy trade-offs for B2B SaaS teams." tldr: "Sage Intacct integration means managing dual REST/XML APIs, Sender ID auth, strict single-concurrency limits, and timezone-less dates. Know the trade-offs before you build." canonical: https://truto.one/blog/how-to-integrate-with-the-sage-intacct-api-a-guide-for-b2b-saas/ --- # How to Integrate with the Sage Intacct API: A Guide for B2B SaaS If your product team just promised a Sage Intacct integration to close a six-figure enterprise deal, here is the short version of what you are signing up for: you will need to work with **two separate APIs** (XML and REST), navigate a multi-layered authentication system involving Sender IDs and Web Services users, stay under strict concurrency limits, and manually handle timezone-less dates. This guide covers each of these challenges in detail so you can make an informed build-vs-buy decision before committing engineering resources. Sage Intacct is a major player in the mid-market cloud ERP space. Gartner classifies Sage Intacct across multiple markets including Cloud ERP for Service-Centric Enterprises and Cloud ERP Finance, and the platform offers core accounting, real-time reporting, accounts payable and receivable, cash management, and project accounting. It handles complex multi-entity consolidation, advanced revenue recognition, and granular general ledger management. Because of this complexity, integrating with its API is not a weekend project. You do not simply generate an OAuth token, hit a `/invoices` endpoint, and call it a day. B2B SaaS companies in the billing and analytics space - like Maxio and Chargebee - invest thousands of engineering hours maintaining these connections to ensure GAAP-compliant data syncs. This guide breaks down the technical requirements of the Sage Intacct API, the architectural hurdles you will face, and how to structure your integration to avoid taking down your customer's accounting system. ## Before You Start: Which Sage Product Are You Integrating With? Sage sells multiple cloud accounting products, and they are often confused with each other. If you searched for "Sage Accounting API" or "Sage Business Cloud Accounting API," you may be looking for a completely different product than the one this guide covers. Getting this wrong wastes weeks of engineering time. **Sage Intacct** and **Sage Business Cloud Accounting** are separate products with separate APIs, separate authentication models, and separate target markets. Here is how they differ from an integration perspective: | | Sage Intacct | Sage Business Cloud Accounting | |---|---|---| | **Target market** | Mid-market and enterprise (multi-entity, complex GL) | Small businesses and startups | | **API surface** | Dual: XML Web Services + REST API | Single REST API (JSON, v3.1) | | **Authentication** | XML: Sender ID + Web Services user; REST: OAuth 2.0 | OAuth 2.0 (standard authorization code grant) | | **Token behavior** | Standard OAuth refresh flow on REST side | Access tokens expire in 5 minutes; refresh tokens rotate on every use | | **Multi-tenant routing** | Company-level Sender ID authorization | `X-Business` header per request; post-auth business discovery required | | **Sandbox availability** | No free sandbox - paid test instance required | Free developer account available | | **Concurrency limits** | Strict: 1 concurrent offline process at default tier | 5,000 API requests per day | | **Formerly known as** | Intacct (acquired by Sage in 2017) | Sage One | The rest of this guide is entirely about **Sage Intacct**. If your customers use Sage Business Cloud Accounting (the simpler, small-business product), read our dedicated guide instead: [How to Integrate with the Sage Business Cloud Accounting API](https://truto.one/blog/how-to-create-a-full-technical-integration-guide-for-sage-business-cloud-accounting/). If your customer base spans both products - common for B2B SaaS companies selling to a mix of SMBs and mid-market firms - you will need to support both APIs. A [unified accounting API](https://truto.one/blog/the-best-unified-accounting-api-for-b2b-saas-and-ai-agents-2026/) can normalize both Sage products (along with QuickBooks, Xero, and NetSuite) behind a single interface. ## Understanding the Sage Intacct API Landscape: REST vs. XML The first architectural decision you have to make is which API to use. **Sage Intacct maintains two distinct APIs: a legacy XML Web Services API and a newer REST API.** Most B2B SaaS teams will need to use both. Sage Intacct recommends using the REST API for client applications. They continue to support the XML API, but going forward all new objects and features will be released using the REST API. As of the 2025 Release 1 (February 2025), the REST API is Generally Available (GA), and Sage is no longer actively developing enhancements for the DTD and XSD schemas that power the XML API. So the REST API is the future. The catch? Since the REST API is newer, not every Sage Intacct module or feature is fully covered, meaning there are still scenarios where XML provides more comprehensive access. When the integration requires deeper functionality, the XML API remains indispensable - some areas of project accounting or fixed asset management have better support in XML because those endpoints have been in use for years and are more mature. This creates a split-brain architecture. Your integration layer must route requests to the REST API for supported objects (like basic Customers or Vendors) while falling back to the XML API for legacy objects. Maintaining two separate API clients, serialization methods, and error-handling routines significantly increases your technical debt—a pain familiar to anyone who has [built a QuickBooks Desktop integration](https://truto.one/blog/how-to-build-a-quickbooks-desktop-integration-without-soap-or-xml/). Sage publishes an [XML-to-REST object map](https://developer.sage.com/intacct/docs/developer-portal/getting-started/xml-rest-object-map) that tells you which objects exist on which API surface. Check it before you start any scoping exercise - it will tell you immediately whether you can stay REST-only or whether you need the XML fallback. ```mermaid flowchart LR A[Your App] --> B{Object on
REST API?} B -- Yes --> C[REST API
JSON / OAuth 2.0] B -- No --> D[XML Web Services
XML / Sender ID Auth] C --> E[Sage Intacct] D --> E ``` > [!WARNING] > **The XML payload reality:** The Sage Intacct XML API uses a highly specific schema (``, ``, ``, ``). If you misplace a single closing tag or use an incorrect element hierarchy, the API will return a generic parsing error that is notoriously difficult to debug. Do not assume the REST API has everything you need just because Sage recommends it. Always cross-reference the XML-to-REST object map against your specific entity requirements (GL accounts, journal entries, AP bills, project accounting objects) before committing to an architecture. ## The Quirks of Sage Intacct Authentication Authentication in Sage Intacct requires more ceremony than most modern APIs. And there are two completely different authentication models depending on which API surface you target. ### XML Web Services Authentication A Web Services request requires two levels of authentication. Your Web Services sender ID must be authorized for use in a given company. Web Services credentials consist of a sender ID and password, provisioned by Sage Intacct for customers/partners with an active Web Services developer license. In practice, this means: 1. **You need a Web Services Developer License** from Sage, which includes a Sender ID and Sender Password. 2. **Each target company must explicitly authorize your Sender ID.** The Web Services authorizations list controls which sender IDs can make requests to a company. If a sender ID is not on this list, any Web Services requests they make will fail. Sender IDs are case-sensitive and cannot be changed after the authorization is added. 3. **You need a dedicated Web Services user.** Web Services users are programmatic and never log in to the UI, with both single-sign on and multifactor authentication automatically disabled for them. You should add a Web Services user for external applications that need a unique user for API calls. 4. It is strongly recommended that you set up a Web Services user account. Although you can send all requests using login authentication, this is not recommended. You should use `getAPISession` to request a session ID and unique endpoint, then make all subsequent requests with this context. This introduces massive friction into your user onboarding process. You cannot just provide a "Connect to Sage Intacct" button. You have to provide your customers with a step-by-step tutorial on how to navigate their Intacct settings, whitelist your Sender ID, and create a dedicated Web Services user with the correct role permissions. This is a four-step onboarding flow *per customer*. Every company that connects to your integration needs to go through this. For a B2B SaaS product with dozens or hundreds of customers on Sage Intacct, that is a support burden that scales linearly. And if the customer uses a standard employee account instead of a dedicated Web Services user, your integration will break the moment that employee changes their password or leaves the company. This is in sharp contrast to Sage Business Cloud Accounting, which uses a standard OAuth 2.0 authorization code flow - your user clicks a button, logs into Sage, grants permission, and you receive tokens. If your customers are on Sage Business Cloud Accounting rather than Sage Intacct, the auth story is much simpler (though it has its own quirks like 5-minute token expiry). See our [Sage Business Cloud Accounting integration guide](https://truto.one/blog/how-to-create-a-full-technical-integration-guide-for-sage-business-cloud-accounting/) for those details. ### REST API Authentication The REST API uses **OAuth 2.0**, which is a much more familiar model. You must have an active Sage Intacct Web Services developer license, which includes a Web Services sender ID and password, or access to a free trial period account. Production companies are limited to no more than five associated API keys, and you cannot change the client scope after it has been set. The OAuth flow is a standard authorization code grant - but you still need the underlying Web Services developer license to register your application in the Sage developer workspace. So even on the REST side, you cannot escape the Sage credentialing process entirely. > [!NOTE] > **Testing pain point:** You need to pay for a full Sage Intacct instance just for testing. There is no free sandbox, no demo environment, and no way to test safely without potential production impact. Budget for this upfront. ## Handling Sage Intacct API Rate Limits and Concurrency Enterprise ERPs are designed to protect their database integrity at all costs. **Sage Intacct enforces both concurrency limits and monthly transaction volume caps, and the defaults on the standard tier are tight enough to trip up most integration workloads.** Sage Intacct implements concurrency limits on REST API calls. These limits prevent any one Sage Intacct customer from consuming server resources at the expense of other customers. Note that concurrency does not equate to the number of integrations. Here is how the Performance Tier system works: | Constraint | Performance Tier 1 (Default) | Higher Tiers | |---|---|---| | Monthly API transactions | 100,000 transactions per month | Up to millions (paid) | | Concurrent offline processes | One (1) concurrent offline process | Multiple (paid) | | API concurrency | Expressed as app/company ratio (e.g., 6/8) | Higher ratios | | Overages | Billed in "packs" of ten transactions | Varies by tier | To prevent a single integration from consuming all available concurrent processes, Sage Intacct provides higher concurrency for a company than for any single integration. This is expressed in the form of application/company - for example, 6/8 indicates that any single application can use up to 6 API processes at a single point in time, while the company can support up to 8 concurrent API processes in total. The real killer is the offline process queue. At the standard Performance Tier 1, Sage Intacct limits each company to one concurrent offline process. Queues for offline processes are shared with other companies. So, it is possible that even if a company only has one job in the queue, they will wait in line behind other companies. The practical impact: if your integration runs a large batch sync while the customer's internal team is running an offline report, one of them waits. And the wait is on shared infrastructure - you are queued behind *other Sage Intacct customers on the same resources.* If your B2B SaaS application tries to sync 50 invoices, update 20 customers, and pull a trial balance report at the same time, the API will reject the overlapping requests. This is a massive problem for high-volume applications. ### Architectural Mitigation Strategies To survive these limits, your architecture must include: - **A strict serial queue:** All write operations for a specific company must be queued and executed sequentially. No concurrent writes, period. - **Batch smartly:** Sage recommends limiting queries to fewer than 1,000 records and paginating the results. When manipulating records, limit the number of affected records to fewer than 100. The XML API allows you to batch multiple operations into a single request - use this to maximize throughput within the single-concurrency constraint. - **Use idempotency:** Set the request's `uniqueid` element to true to enforce idempotence for the functions in that request - this protects you against mid-process failures and duplicate records. - **Implement exponential backoff:** Sage enforces rate limiting to ensure all API requests can be processed according to contracted levels of service. A 429 error indicates that your API client has hit its assigned rate limit. When the API returns a concurrency error, your worker must pause, back off, and retry. - **Cache aggressively:** Read-heavy operations like fetching the chart of accounts, tax rates, or contact lists can be cached locally to avoid burning through your monthly allocation. For more on handling rate limits across providers, see our guide on [how to normalize pagination and error handling across 50+ APIs](https://truto.one/blog/how-to-normalize-pagination-and-error-handling-across-50-apis-without-building-it-yourself/). ## Data Formatting Traps: Timezones and ISO 8601 Date and time handling is one of the most common sources of bugs in accounting integrations. Most modern APIs standardize on ISO 8601 formats (e.g., `2026-10-15T14:30:00Z`), which explicitly define the timezone. **Sage Intacct's XML API does not support ISO 8601 date formats, and dates in the system do not carry timezone information.** This is the kind of detail that does not show up in sprint planning but causes production incidents. Dates in Sage Intacct do not have associated timezones. ISO 8601 date formats are not supported in Sage Intacct. An integration that uses these formats must translate them into accepted date formats. The XML API expects dates in `mm/dd/yyyy` format for most generic functions. Some audit trail functions use `MM/DD/YYYY HH:MM:SS`. The REST API is more forgiving, but the underlying data model still does not carry timezone metadata. What this means for your integration: - **Every write requires date conversion.** A date like `2026-03-15T14:30:00Z` needs to become `03/15/2026` before it hits the XML gateway. - **Every read requires timezone inference.** When you pull a transaction date from Sage Intacct, it might just say `10/15/2026`. Is that October 15th in Pacific Time? Eastern Time? London? The API will not tell you. You need to know what timezone the company configured in their Sage Intacct instance and apply it yourself. - **Watch for daylight saving time transitions.** A transaction recorded at 11 PM Pacific on the last day of Q1 could end up on the wrong date depending on your timezone handling. If your SaaS application operates in UTC and you push an invoice date to Sage Intacct without manually offsetting it to the customer's local timezone, you risk recording revenue in the wrong fiscal period. In enterprise accounting, a revenue recognition error caused by a timezone bug is a catastrophic failure. For a deeper look at how schema differences compound across providers, read [why schema normalization is the hardest problem in SaaS integrations](https://truto.one/blog/why-schema-normalization-is-the-hardest-problem-in-saas-integrations/). ## Architectural Patterns for High-Volume Data Syncs Given the constraints of the dual API surface, the strict concurrency limits, and the lack of standard webhooks for many objects, you have to design a highly resilient sync engine. Polling an ERP for changes is expensive, but often necessary. ```mermaid graph TD A[B2B SaaS Application] -->|Write Request| B(Internal Job Queue) B -->|Dequeue 1 by 1| C{API Router} C -->|Supported Object| D[Sage Intacct REST API] C -->|Legacy Object| E[Sage Intacct XML API] D --> F[(Sage Intacct Database)] E --> F F -->|Concurrency Error| B classDef default fill:#f9f9f9,stroke:#333,stroke-width:2px; ``` When architecting this flow, you must implement a system that tracks the `RECORDNO` (Sage Intacct's internal primary key) alongside your application's internal IDs. Because Sage Intacct allows users to rename entities and change display IDs, relying on anything other than the immutable `RECORDNO` will result in duplicate records and corrupted ledgers. This is a subtle but critical detail that will not surface until you have customers actively using the integration in production. Your queue must be partitioned per-company so that one customer's large sync job does not block another customer's small update. And every job in the queue must be idempotent - if a job fails halfway through due to a concurrency rejection, you need to be able to replay it safely without duplicating writes. ## Building vs. Buying Your Sage Intacct Integration Let us tally up what building a Sage Intacct integration in-house actually requires: - **Two API clients** - one for REST (JSON/OAuth 2.0), one for XML (Sender ID auth with a specific XML schema) - **Custom date translation layer** - converting between ISO 8601 and Sage's proprietary formats, with manual timezone handling - **Rate limit management** - exponential backoff, request queuing, concurrency control, and monthly transaction budgeting - **Per-customer onboarding flow** - collecting Sender IDs, authorizing your sender in each company, setting up Web Services users, writing support documentation - **Ongoing maintenance** - Sage continues shipping new objects on REST while the XML API stays frozen; you need to track which surface covers which objects and migrate accordingly If you choose to build in-house, your engineering team is signing up for a multi-month project. And once it is built, you have to maintain it. When Sage Intacct migrates a legacy object from the XML API to the REST API, you will have to rewrite your integration logic for that object. If Sage Intacct is the only accounting system your customers use and the scope is narrow (say, syncing invoices), building in-house might be justifiable. The math changes fast when your customer base also includes [QuickBooks Online](https://truto.one/blog/how-to-integrate-with-the-quickbooks-online-api-2026-guide/), Xero, and [NetSuite](https://truto.one/blog/the-final-boss-of-erps-architecting-a-reliable-netsuite-api-integration/) users - each with their own authentication quirks, pagination models, and entity naming conventions. This is the exact scenario where a [unified accounting API](https://truto.one/blog/the-best-unified-accounting-api-for-b2b-saas-and-ai-agents-2026/) earns its keep. Instead of maintaining four or five separate integration codebases, you integrate once against a standardized schema and let the abstraction layer handle the provider-specific translation. For an honest breakdown of build-vs-buy economics, including hidden maintenance costs, see our analysis in [Build vs. Buy: The True Cost of Building SaaS Integrations In-House](https://truto.one/blog/build-vs-buy-the-true-cost-of-building-saas-integrations-in-house/). ## How Truto Handles Sage Intacct Truto's Unified Accounting API maps Sage Intacct entities - Customers, Invoices, GL Accounts, Bills, Payments, Journal Entries - into the same standardized schema that works identically across QuickBooks, Xero, and NetSuite. The platform handles the dual REST/XML routing, date format translation, rate limit management with exponential backoff, and OAuth token lifecycle automatically. Here is what a unified API call looks like - no XML, no Sender IDs, no date format juggling: ```bash curl -X GET "https://api.truto.one/unified/accounting/invoices?integrated_account_id=YOUR_SAGE_INTACCT_ACCOUNT" \ -H "Authorization: Bearer YOUR_TRUTO_API_KEY" ``` The response comes back in a normalized JSON schema regardless of whether the underlying data was fetched from Sage Intacct's REST API, its XML gateway, or a combination of both. Here is how the unified approach solves the specific Sage Intacct challenges: - **Zero XML parsing:** You interact with a modern, JSON-based Unified Accounting API. Truto handles the translation to Sage Intacct's required format behind the scenes. - **Automated concurrency management:** If you fire 50 concurrent requests to create invoices, the platform schedules the work and executes it within Sage Intacct's limits, returning standardized success or failure states. - **Standardized dates:** The unified schema enforces ISO 8601 date formats. Truto handles the translation between your UTC timestamps and Sage Intacct's timezone-less strings. - **Normalized pagination:** You use standard offset/limit parameters. No custom logic for Sage Intacct's specific cursor pagination. But let me be honest about the trade-offs: - **Deep Sage Intacct customizations** - If your customers use heavily customized Platform Services objects, a unified schema will not cover every custom field out of the box. You may need Truto's Proxy API to access provider-specific resources directly. - **Niche modules** - Project accounting, fixed asset management, and some inventory control functions may not be fully mapped in any unified model. Ask about coverage for specific objects before committing. - **You still need to understand the domain** - A unified API abstracts the API complexity, not the accounting complexity. You still need to know how double-entry accounting works, what a GL posting is, and why you cannot just delete an applied payment. ## What to Do Next If you are starting a Sage Intacct integration project, here is a practical checklist: 1. **Audit your entity requirements** against Sage's [XML-to-REST object map](https://developer.sage.com/intacct/docs/developer-portal/getting-started/xml-rest-object-map). Know exactly which API surface you need before writing a line of code. 2. **Budget for a paid Sage Intacct test instance.** There is no free sandbox. No demo environment. No way to test safely without paying. 3. **Estimate your monthly API transaction volume.** If you will exceed 100,000 transactions per month, factor in Performance Tier upgrade costs or overage fees. 4. **Decide build vs. buy early.** If you need to support multiple accounting platforms (not just Sage Intacct), a unified API will save you months of engineering time. If it is Sage Intacct only with deep customization needs, building in-house may give you more control. 5. **If going unified, validate coverage.** Ask your provider for a specific entity-by-entity coverage matrix for Sage Intacct, not just a marketing checkbox. > Need to ship a Sage Intacct integration without building two API clients? Truto's Unified Accounting API normalizes Sage Intacct alongside QuickBooks, Xero, and NetSuite into a single schema. Talk to our team to see the coverage matrix for your specific use case. > > [Talk to us](https://cal.com/truto/partner-with-truto)