Connect NetSuite#
Difficulty: heavy (Token-Based Auth). NetSuite is an ERP-grade premium connector. Connecting it means setting up Token-Based Authentication (TBA) in NetSuite — more steps than an OAuth click-through, but a one-time job.
Auth at a glance#
| Method | Token-Based Authentication (OAuth 1.0a, HMAC-SHA256) |
| What you create | An integration record + an access token (4 secrets) |
| Where Forge helps | Forge builds every signed request; you create the token once |
What you'll need#
- A NetSuite account with administrator access.
- The Token-Based Authentication feature enabled.
- Your NetSuite account id (the realm, e.g.
1234567or1234567_SB1for a sandbox) — this is non-secret config, not a credential.
The four secrets#
TBA signs each request with four values. Forge needs all four, stored encrypted in the credential store:
| Secret | Where it comes from |
|---|---|
| Consumer key | The integration record you create |
| Consumer secret | The integration record (shown once) |
| Token id | The access token you create |
| Token secret | The access token (shown once) |
Steps#
- Enable TBA. Setup → Company → Enable Features → SuiteCloud → check Token-Based Authentication.
- Create an integration record. Setup → Integration → Manage Integrations → New. Enable Token-Based Authentication, disable the parts you don't need, save. NetSuite shows the consumer key/secret once — copy them now.
- Create a role with the permissions for the records you'll sync, and assign it to the integration user.
- Create an access token. Setup → Users/Roles → Access Tokens → New. Pick the integration, user, and role. NetSuite shows the token id/secret once — copy them now.
- In Connections, choose NetSuite → Connect. Enter the account id and the four secrets.
Gotchas#
- The secrets are shown exactly once. If you navigate away without copying the consumer secret or token secret, you must regenerate. Have a safe place ready.
- Account id form matters. Sandboxes use
<account>_SB1; the REST host is derived from it. A wrong realm yields signature failures that look like auth errors. - Role permissions are the usual culprit. A 403 on a record almost always means the role is missing a permission for that record type — fix the role, not the token.
- External-id upsert is native. NetSuite supports
PUT eid:upsert, so Forge keys writes on your external id directly with no search race.
What Forge provisions for you#
Forge can't create the NetSuite integration record or token for you — NetSuite requires an administrator to do that in-product, and the secrets are deliberately shown only to that person. What Forge does take off your plate is everything after: the OAuth 1.0a request signing, the realm-specific host resolution, the error taxonomy, and the snapshot/verify/rollback on every write.
Note: NetSuite is built and mock-tested; live verification against a NetSuite account follows the same upsert → verify → delete → confirm-gone proof as the other connectors.