Setting Up the Sage Intacct Connector

Connect Sage Intacct into Wazzi via OAuth 2.0 — General Ledger, AP, AR, journal entries, payments, and 2,000+ endpoints exposed as MCP tools.

May 22, 2026
8 min read

Path: Connectors → Sage Intacct → Configuration

What this connector does

The Sage Intacct connector exposes the modern Sage Intacct REST API to Wazzi as MCP tools — General Ledger, Accounts Payable, Accounts Receivable, Cash Management, Order Entry, Purchasing, Time & Expense, Projects, and more. The full Sage REST API surface is about 2,000 endpoints; Wazzi exposes a curated set of typed tools for the most common financial workflows plus a universal query tool and a raw endpoint escape hatch that together can reach every Sage object.

Wazzi authenticates via OAuth 2.0 client credentials. A registered application in the Sage Developer Portal issues a client_id and client_secret; Wazzi exchanges those plus a Sage user identifier for short-lived OAuth access tokens (12-hour lifetime, auto-refreshed and cached). No per-user OAuth flows — one set of credentials per Wazzi organization.

Before you start — getting your OAuth credentials

You'll need:

  • A Sage Intacct Web Services subscription (your accounting team or Sage account manager can confirm).
  • A Sender ID and Sender Password issued by Sage (provisioned when your Web Services license was set up).
  • Admin access to your Sage Intacct company.
  • An account on the Sage Developer Portal at developer.sage.com/intacct.

Step 1 — Register an OAuth application in the Developer Portal

  1. Sign in to developer.sage.com/intacct with the account tied to your Sender ID.
  2. Go to My Apps → Create App (or Register Application).
  3. Fill in the app form:
    • App name: Wazzi MCP (or similar).
    • Redirect URL: any HTTPS URL you control — for example https://api.wazzi.io/oauth/sage/callback. Required by OAuth spec for registration, but never invoked at runtime by the client-credentials flow.
    • Asynchronous Callback URIs: leave blank. Used only for long-running operations (bulk imports / exports), which Wazzi doesn't call from this connector.
    • Allowed origin domains: leave blank. CORS only matters for browser-side calls; Wazzi calls Sage from the server side.
  4. Submit the form. The app's detail page shows your Client ID and Client Secret. Copy both. The secret is shown only once — if you lose it, regenerate.

Step 2 — Authorize the Sender ID against your company

This is the step that's easiest to miss. Without it, Sage rejects the token request with "Invalid sender ID" even when client_id and client_secret are correct.

  1. Log in to Sage Intacct as a company admin (the app, not the Developer Portal — usually at https://www.intacct.com).
  2. Go to Company → Setup → Subscriptions → Web Services.
  3. Under Sender IDs, add the Sender ID Sage assigned to you. Mark it active. Save.

Step 3 — Create (or pick) the Sage user the connector will run as

Sage's OAuth client-credentials flow runs as a specific Sage user — that user's role and permissions determine what the access token can read or write. Best practice is a dedicated integration user, not a personal account.

  1. In Sage Intacct, go to Company → Admin → Users.
  2. Click + Add.
  3. Set:
    • User ID: e.g. wazzi-api. This becomes the first half of your username field below.
    • User type: Business User (or Employee, depending on what your roles allow).
    • Roles: assign the minimum required. AP-read / AR-read / GL-read for read-only access; add Create / Submit roles for posting bills and journal entries.
    • Web Services Authorization: ensure the user is allowed to be used by Sender ID-based integrations.
  4. Save the user.

Step 4 — Note your Company ID

Go to Company → Settings → Information. The Company ID field at the top — short alphanumeric, e.g. AcmeHouseCo — is the second half of the username field below. It is not the company name.

Reference: Sage's official OAuth 2.0 guide is at developer.sage.com → OAuth 2.0 authorization.

What this connector unlocks for your team

Once configured, members with the right MCP permissions can ask Claude / ChatGPT / Cursor things like:

  • "List all open AP bills over $5,000 due in the next 30 days."
  • "Show me the journal entry totals by department for last month."
  • "Create a vendor bill for Acme Maintenance for $1,250 against GL account 6100."
  • "Pull the trial balance for Q1 by account category."
  • "Who are our top 10 customers by outstanding invoice balance?"

The exact set of available actions depends on (a) the role you assigned to the dedicated Sage user, and (b) which MCP toggles are flipped on for the user's group in Wazzi — see Managing Permissions.

Steps — configuring Sage Intacct in Wazzi

1. From the Connectors catalog, click Configure on the Sage Intacct tile.

You'll land on Sage's Configuration tab:

Sage Intacct connector Configuration tab

2. Fill in the three fields.

  • Client ID — from the Sage Developer Portal app you registered in Step 1.
  • Client Secret — same place. Encrypted at rest in Wazzi.
  • Username — the integration user joined to your Company ID, in the form UserID@CompanyID. Example: wazzi-api@AcmeHouseCo. If you operate with location-pinned authentication, append |LocationID, e.g. wazzi-api@AcmeHouseCo|Phoenix. Most setups omit the |Location part.

3. Click Test Connection.

Wazzi POSTs your credentials to https://api.intacct.com/ia/api/v1/oauth2/token, gets back an access token, then calls GET /company-config to confirm the token works. Success shows the company name returned by Sage; failure surfaces the auth error verbatim.

4. Click Save Configuration.

Sage Intacct moves to the Active section of the catalog and the dot turns green.

Troubleshooting

  • "Invalid sender ID" — Your Sender ID isn't authorized in the company's Web Services subscription. Go to Company → Setup → Subscriptions → Web Services in Sage Intacct and add it (Step 2 above).
  • "Invalid client credentials" — Client ID or Client Secret is wrong, or they're from a different Developer Portal app than the one tied to the active Sender ID. Re-copy from the app's page in the Developer Portal — surrounding whitespace is the usual culprit.
  • "Invalid user" or "User not authorized for web services" — The user portion of the username field doesn't exist in this Sage company, or the user isn't authorized for web services. Verify the User ID in Company → Admin → Users and that web services access is enabled on that user.
  • "Invalid company" — The @CompanyID portion doesn't match this Sage tenant. Confirm in Company → Settings → Information (it's the short alphanumeric ID, not the company name).
  • "Permission denied" / 403 on a specific tool. The Sage user's role doesn't include access to that module. Open the user in Company → Admin → Users, add the missing role, and retry.
  • Test Connection works but tool calls return 429. Sage rate-limits at roughly 30 requests/minute per company. Wazzi caches the access token to avoid wasted token requests, but high-volume calls may still hit the cap. Spread out heavy operations or contact Sage to increase the limit on your tier.

Best practices

  • Use a dedicated integration user. Don't reuse a human admin account. A user called wazzi-api with a specific role set makes auditing, revocation, and rotation trivial.
  • Role-minimize. If your team only needs read access to AP/AR/GL, give the user only those roles. Add Create / Submit roles when you actually need posting.
  • Rotate credentials periodically. Regenerate the Client Secret in the Developer Portal every quarter and update Wazzi.
  • Restrict who can invoke posting actions in Wazzi. Creating bills, journal entries, and payments mutates your books. Only grant create permissions to groups that need them — see Managing Permissions.
  • Keep Sender ID + Sender Password out of the Wazzi UI. They aren't entered into Wazzi — they live in the Developer Portal where they tied your Client ID/Secret to a company. Treat them like the master keys they are.

Frequently asked questions

Does Wazzi store my credentials in plaintext?
No. Client Secret and Username are encrypted at rest with per-org keys. Access tokens are cached in memory (12-hour lifetime) and not persisted in their decrypted form.

Can I run multiple Sage Intacct companies?
Sage is a single-instance connector. If you need to connect more than one Sage company, file a feature request for multi-instance support (similar to how the High Level connector works).

Why does the username look like an email address?
It isn't. The @ in wazzi-api@AcmeHouseCo is Sage's separator between User ID and Company ID. It's not a real email — don't try to send mail to it.

Does Wazzi use the legacy XML/SOAP API at all?
No. The Sage Intacct connector talks exclusively to the modern REST API at api.intacct.com/ia/api/v1. The legacy sender_id / sender_password XML payloads are not used at runtime.

What if I need an endpoint that doesn't have a typed tool?
Two universal tools cover the long tail. query can list records from any Sage object via Sage's universal /services/core/query endpoint. call_sage_endpoint is a raw escape hatch — call any Sage REST path with any HTTP method, query, and body. Between them, every one of Sage's 2,000+ endpoints is reachable.

What's next

Was this article helpful?