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). 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 Sender ID and Sender Password issued by Sage Intacct (see Step 1).

Step 1 — Configure your gateway credentials (Sender ID)

The Sender ID and password are your Sage Intacct Web Services gateway credentials. Only Sage Intacct can issue them — contact your Sage Intacct account manager to request a Sender ID for your integration.

Then, in the Apideck dashboard, open your Sage Intacct integration settings (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 apply to all consumer connections created on this integration.

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.

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.

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