Send leads to NetSuite

NetSuite is the one connection here that signs every request rather than carrying a token. Its token-based authentication is OAuth 1.0a: five values you create once inside NetSuite, and a signature computed per call from the method, the URL and the parameters.

Nothing about it expires on a timer, and nothing has to be refreshed.

What you need

Two features enabled, two records created, five values written down.

Under Setup, Company, Enable Features, SuiteCloud, tick Token-Based Authentication and REST Web Services.

Then:

• An integration record (Setup, Integration, Manage Integrations, New) with token-based authentication ticked. It gives you a consumer key and a consumer secret, shown once.
• An access token (Setup, Users/Roles, Access Tokens, New) for the role that will create the records. It gives you a token id and a token secret, also shown once.
• Your account id, from Setup, Company, Company Information. A sandbox looks like 1234567_SB1.

If you missed one of the "shown once" values, the fix is to make a new one. NetSuite will not show it again, and neither would we.

Sandbox accounts

A sandbox answers on its own host, derived from the account id: 1234567_SB1 becomes 1234567-sb1.suitetalk.api.netsuite.com. You do not have to work that out -- paste the id as NetSuite writes it and the host follows.

Connect and route

1. In Destinations, connect NetSuite with the account id and the four values. We verify with one read, which proves the five values, the signature and the role together.
2. Pick the record type: Customer, Contact or Opportunity.
3. Create a route -- which leads it takes, and which record they become.
4. Map the fields. They come from the record type's own schema, so what you see is what your account will accept.

Lead or customer

In NetSuite a lead is not a separate record type. It is a customer at an early stage, with a status that moves as the relationship does. Creating a customer is creating the lead; the stage is yours to set in NetSuite.

What gets sent

Only writable fields from the record's schema. Fields that hold another record -- a subsidiary, a sales rep, a currency -- are left out of the mapper, because they want that record's internal id and a string typed into a chat is not one.

Values are shaped per field. A number field takes the digits out of what the visitor typed. A checkbox reads yes, no, true, false, 1 and 0. A date becomes YYYY-MM-DD.

A customer needs a name. One is filled in from what the lead carries when the mapping leaves it out, as a person rather than a company, so a route never loses a lead over a blank field.

A date worth knowing

Oracle's documentation says that from 2027.1 no new integrations using token-based authentication can be created for REST web services. Existing ones keep working. A connection made today is unaffected; one made after that release will need OAuth 2.0, which for NetSuite means a signed assertion and a certificate rather than a secret. We will support it before it is needed.

Common errors

INVALID_LOGIN_ATTEMPT covers almost everything: a wrong value, a token issued for a different account, or a signature that did not match. It does not say which, by design. Re-check the account id first -- it is the value people most often paste with the wrong case or the wrong separator.

A permission error rather than a login error means the five values are right and the role the access token carries may not create that record type.

What it does not do

It creates. It does not update an existing record, and it does not deduplicate. Custom record types are not offered yet.