Getting started with Sage Intacct

This guide is for you, the Apideck customer building an integration. It covers configuring your Sage Intacct gateway credentials, how a connection is set up, and how to work with multi-entity companies.

Sage Intacct authenticates through its XML Gateway using a partner-level Sender ID (there is no OAuth app to register and no redirect URL). The Sender ID identifies your integration to every Sage Intacct company that connects; each connecting customer then authorizes that Sender ID inside their own company and provides their own Web Services user credentials.

Prerequisites

An Apideck account with the Sage Intacct connector enabled (Unify → Configure → Sage Intacct).
A Sage Intacct Web Services developer license — the Sender ID and Sender Password issued by Sage (see Step 1).

Step 1 — Get your Web Services developer license (Sender ID)

A Web Services developer license is required. It is what issues the Sender ID and Sender Password that identify your integration to the gateway. Only Sage Intacct can issue them: there is no self-service developer portal for this API.

The route is the Sage Intacct Marketplace Partner Program: Sage's own developer FAQ answers the "how do I get a Web Services developer license" question by pointing at the Become a Partner application. There is no self-service alternative and no existing account manager to contact for it — Apideck facilitates the introduction to Sage's Marketplace Partner team; reach out to Apideck Support to get that conversation started.

What Sage's approval involves

Approval is a review process with several stages, not a single application form. Through the Marketplace Partner Program you can expect to work through:

Security questionnaire: Sage assesses your application and how it handles customer data.
Discovery meeting: a call covering your integration, its use case and your target customers.
Partner contract execution: signing the Marketplace Partner agreement. This milestone is referenced twice below: it starts the annual membership fee (see Costs) and it is when Sage provisions your sandbox (see Sandboxes).
Development: you build the integration, normally against the sandbox Sender ID.
API review: Sage reviews how your integration uses the API.
Technical documentation: the integration documentation Sage requires from you.
Live demo call: a walkthrough of the finished integration with Sage.

Ask your Sage partner contact what each stage requires from you and for an expected timeline; they own the schedule and are the only people who can tell you where your application stands.

Costs

Marketplace Partner Program membership fees are due net 30 from execution of the partner contract, and Sage charges API consumption fees once your consumers are live on the integration. See the Costs row on the connector's Overview tab for current pricing.

Add your credentials in Apideck

Once Sage has issued them, open your Sage Intacct connector settings in the Apideck Dashboard (Sage Intacct Credentials) and fill in:

Field	Description
Sender ID	The Sender ID issued by Sage Intacct (case-sensitive).
Sender Password	The password for that Sender ID.

These are set once at integration level and apply to all consumer connections created on this integration. Your consumers never see or supply them — they supply their own Company ID, User ID, Password and Default Entity when they connect.

Step 2 — How a connection works

Each connecting customer, in their own Sage Intacct company:

Creates a Web Services user and grants it the required permissions.
Authorizes your Sender ID under Company → Setup → Company → Security → Web Services authorizations.
Provides their Company ID, User ID, Password, and Default Entity in Vault.

Point your consumers to the connection guide for the full walkthrough.

Default Entity decides what the connection can see and where it writes: Top level works across the whole company (shared/top-level data), while a specific entity scopes the connection to that entity. This is the key setting behind the multi-entity behaviour below.

Sandboxes

Two sandbox options exist, and both run on a Sender ID that is separate from your production one:

Sage-provisioned sandbox — when your Marketplace Partner contract is executed, Sage provisions a sandbox company with its own Sender ID.
Apideck temporary shared sandbox — Apideck offers a temporary shared sandbox that runs on Apideck's own Sender ID. It is available under an enterprise contract; your Apideck account contact can arrange access.

Sandbox Sender ID credentials are scoped to sandbox companies and cannot be used against production consumer accounts. Swap in your production Sender ID and Sender Password before inviting real customers to connect.

Network and connection limits

IP whitelisting is not required for the Sage Intacct XML Gateway, so there is no address allow-list for you or your consumers to maintain.
Apideck imposes no limit on the number of connections you create against this integration. That is an Apideck-side statement about connection count, not about throughput: Sage Intacct applies its own per-company transaction and concurrency limits, which every connection into that company shares. See the Rate limits row on the connector's Overview tab before sizing a high-volume integration.
Large reads cost more than one transaction. Sage caps a query page at 2,000 records, so a read that spans more pages spends one transaction per page fetched against the monthly allowance. Size backfills and full syncs with that in mind.

Multi-entity companies

Sage Intacct companies are often multi-entity: one company with many entities (e.g. one entity per location or subsidiary). Entity scope is a property of the session — fixed when the connection authenticates — not of individual records.

Choosing a connection model

One connection per entity (recommended when write performance matters): each connection's Default Entity is a specific entity. Fastest — no per-request scoping overhead — at the cost of managing one connection per entity.
A single top-level connection (Default Entity = Top level): one connection for the whole company, routing per request (below). Fewer connections; writes to a non-default entity pay a one-time extra login per entity (see Performance).

Reads — cross-entity visibility (`show_private`)

A top-level connection returns only top-level / shared records by default; records in private entities are hidden. Opt in per request to include them:

GET /accounting/bills?pass_through[show_private]=true

This enables Sage Intacct's native showprivate query option. It is opt-in and off by default — enabling it changes the result set and total_count. It applies across accounting list endpoints (bills, invoices, payments, credit-notes, journal-entries, customers, suppliers, and more) and is meaningful only for a multi-entity company queried from a top-level connection.

A few list endpoints do not yet accept pass_through (expenses, employees, expense-categories, expense-reports); support there is tracked separately.

Writes — per-request entity routing

To create or update a record in a specific entity from a top-level connection, target the entity per request in either of two ways (if both are given they must match):

Header: x-apideck-company-id: <entityId>
Body: subsidiary: { "id": "<entityId>" }

If the target equals the connection's Default Entity (or is omitted / top-level), the request behaves normally with no extra work.

Per-request entity routing is supported on these write operations (both create and update): bills, invoices, credit-notes, journal-entries, payments, bill-payments, customers, and suppliers. For customers and suppliers — which are top-level-shared master data by default — this lets you optionally own a record in a specific entity; the owning entity is then reflected back on reads via the record's subsidiary field.

Other write endpoints (e.g. ledger-accounts, expenses, expense-reports, bank-accounts, employees, tracking-categories) do not yet honor per-request entity routing; support there is tracked separately.

Performance

Writing to a subsidiary that is not the connection's own entity — i.e. targeting a different entity via the x-apideck-company-id header or the subsidiary body field — is slower: the connector has to open a short-lived entity-scoped Sage session for that target before it can post. That is one extra login round-trip the first time each entity is hit (per warm instance); the scoped session is then cached and reused, so steady-state overhead is zero, but the cost re-appears on cold starts and the first write to each new entity.

For the fastest writes, configure one connection per subsidiary (each connection's Default Entity set to that subsidiary). Then every write already runs in the right entity's session — no per-request re-scoping, no extra login. Use the single top-level connection + x-apideck-company-id / subsidiary approach when minimizing the number of connections matters more than that occasional extra login.

Goal	Approach
Fast writes, clear per-entity routing	One connection per entity (Default Entity = the entity)
One connection, occasional extra write latency acceptable	Top-level connection + `x-apideck-company-id` / `subsidiary`
Read across all entities from one top-level connection	`?pass_through[show_private]=true` on list reads