NetSuite has officially documented the deprecation of Token-Based Authentication (TBA) for SOAP web services, REST web services, and RESTlets. Celigo is explicitly named in Oracle's documentation as a third-party connector that will require updates. If your business runs Celigo flows against NetSuite, this migration is not optional — but it is manageable, and the sooner you plan for it, the less disruptive it will be.
NetSuite TBA Deprecation — At a Glance
- Key dates: NetSuite 2027.1 (~Feb–Mar 2027) — no new TBA integrations; NetSuite 2028.1 (~Q1 2028) — all existing TBA stops working
- Am I affected? Open your Celigo NetSuite connection — if it shows Consumer Key, Consumer Secret, Token ID, and Token Secret, you are using TBA and are in scope
- Not affected: Connections showing Client ID + Client Secret (OAuth 2.0 already); SuiteAnalytics Connect ODBC/JDBC is explicitly excluded
- What replaces it: OAuth 2.0 Machine-to-Machine (client credentials grant) — generate a Client ID and Secret in NetSuite, update the Celigo connection, test in sandbox
- Migration time: 2–4 weeks per integration for planning, testing, and go-live; start now to avoid deadline pressure in 2027
- Risk if ignored: All TBA-based Celigo flows will fail to authenticate against NetSuite when 2028.1 releases
This does not break anything today. TBA continues to work until 2028.1. The purpose of this article is to give you the full picture so you can migrate on your timeline — not under deadline pressure.
What is Token-Based Authentication?
Token-Based Authentication is NetSuite's implementation of OAuth 1.0 for machine-to-machine API access. To authenticate, an integration holds four credentials:
- Consumer Key and Consumer Secret — issued when you create an Integration record in NetSuite
- Token ID and Token Secret — issued when you create an Access Token for a specific employee/role
On every API call, these four values are combined with request-specific data (timestamp, nonce, HTTP method, URL) to produce a cryptographic signature, which is sent in the Authorization header. NetSuite validates the signature on every request.
TBA has been a widely used NetSuite integration auth method for nearly a decade. Many Celigo-NetSuite connections use TBA, as do integrations built on Boomi, MuleSoft, Informatica, and other iPaaS platforms — but not all. Some deployments already use OAuth 2.0, in which case the deprecation does not apply.
The deprecation timeline
Timeline from Oracle NetSuite documentation: Token-Based Authentication Deprecation (section 0525020842).
All existing TBA integrations continue to work. No action required — but migration planning should begin.
~Feb–Mar 2027
You can no longer create new Integration records with TBA enabled for SOAP, REST, or RESTlets. Existing TBA integrations keep working.
Tentative
All TBA-based authentication stops working. Any integration still using TBA at this point will fail to authenticate.
Exception: SuiteAnalytics Connect (ODBC/JDBC) is explicitly excluded from this deprecation. If you use Celigo with SuiteAnalytics Connect for reporting or data extraction, those connections are not affected.
Which Celigo integrations are affected
To check: in Celigo, open your NetSuite connection and look at the authentication type. If it shows Consumer Key, Consumer Secret, Token ID, and Token Secret — that is TBA, and you are in scope. If it shows Client ID and Client Secret (OAuth 2.0), you are already on the modern standard and not affected.
TBA-based Celigo connections typically include:
- All Celigo flows using the NetSuite connector (the standard SuiteApp-based connector)
- Celigo flows hitting custom RESTlets in NetSuite via TBA
- Any HTTP adapter calls to NetSuite REST or SOAP APIs that sign with TBA credentials
Not affected: SuiteAnalytics Connect ODBC/JDBC connections, and any Celigo connection already using OAuth 2.0.
What replaces TBA: OAuth 2.0 machine-to-machine
OAuth 2.0 M2M uses the client credentials grant type — the standard for server-to-server integrations where no human login is involved. Instead of four TBA credentials and per-request signing, OAuth 2.0 M2M works in two steps:
- Token request: Your integration sends its Client ID and Client Secret to NetSuite's token endpoint and receives a short-lived access token (Bearer token).
- API call: Every subsequent API request includes the Bearer token in the Authorization header. NetSuite validates the token, not a per-request signature.
The access token expires (typically after 60 minutes). Your integration — or Celigo on your behalf — requests a new token before expiry. This is handled automatically by any properly implemented OAuth 2.0 client.
| Aspect | TBA (OAuth 1.0) | OAuth 2.0 M2M |
|---|---|---|
| Credentials held | Consumer Key, Consumer Secret, Token ID, Token Secret (4 values) | Client ID, Client Secret (2 values) |
| Auth per request | Sign each request with cryptographic signature | Bearer token in Authorization header |
| Token expiry | No expiry — credentials are permanent | Access token expires (~60 min), refreshed automatically |
| Setup complexity | Moderate — Integration record + Access Token in NetSuite | Slightly simpler — connected app in NetSuite |
| Industry standard | Legacy — OAuth 1.0 is rarely used outside NetSuite | Modern standard used by all major platforms |
What changes in your Celigo setup
The migration is a connection-layer change only. Your flow logic — field mappings, filters, transformation scripts, error handling rules, sync schedules — stays completely intact. You update the NetSuite connection credentials in Celigo from TBA to OAuth 2.0, and your flows continue running against the same API endpoints.
Current Celigo support for OAuth 2.0 M2M: As of 2026, OAuth 2.0 Client Credentials (M2M) can be configured in Celigo using the HTTP connection type with JWT token handling — documented in the Celigo community. The native NetSuite connector is expected to add M2M support ahead of the 2027.1 milestone. Watch Celigo's release notes and the Celigo community forum for the update. Entech Solutions, as a Celigo certified partner, is tracking this and will assist clients with the migration.
Some Celigo connections use OAuth 2.0 Authorization Code Grant — a different OAuth 2.0 flow that requires a user login step and has a 7-day refresh token expiry. This is not the same as OAuth 2.0 M2M (Client Credentials), and is not suitable for unattended automation. The TBA deprecation does not affect either OAuth 2.0 flow — but if your connection uses OAuth 2.0 Authorization Code, verify your refresh token rotation is configured or you risk manual re-authentication every 7 days.
Setting up OAuth 2.0 in NetSuite (preparation steps)
You can set this up in sandbox today to familiarize yourself with the new flow before your production migration:
- Go to Setup → Integration → Manage Integrations → New
- Name the integration (e.g. "Celigo OAuth 2.0"), enable OAuth 2.0 and select Machine-to-Machine as the grant type
- Save — NetSuite generates a Client ID and Client Secret. Copy both immediately; the secret is shown only once.
- Note your NetSuite token endpoint:
https://<accountId>.suitetalk.api.netsuite.com/services/rest/auth/oauth2/v1/token - When Celigo's native connector adds OAuth 2.0 M2M support (or using the HTTP connection workaround now), enter the Client ID and Client Secret into the connection configuration
Steps to take now
- Audit your Celigo connections. In Celigo, go to Resources → Connections and identify every connection pointing to NetSuite. Note which flows depend on each connection.
- Document your TBA credentials. For each NetSuite connection, note which Integration record and Access Token it uses in NetSuite. This makes the migration mapping straightforward.
- Set a calendar reminder for Q1 2027. That is when you need Celigo's OAuth 2.0 connector update installed and tested in sandbox before 2027.1 lands.
- Test OAuth 2.0 in sandbox. Create an OAuth 2.0 Integration record in your NetSuite sandbox now. Validate that you can obtain a Bearer token using the client credentials flow. This removes one variable when the actual Celigo migration happens.
- Talk to your Celigo partner. If you work with an implementation partner, loop them in now so migration is part of your 2026–2027 roadmap, not a surprise.
FAQs
- When exactly does NetSuite stop supporting TBA?
- Two milestones: NetSuite 2027.1 (~February–March 2027) stops new TBA integration creation. NetSuite 2028.1 (tentative, ~early 2028) ends all TBA support. SuiteAnalytics Connect ODBC/JDBC is excluded.
- Will my existing Celigo flows break in 2027.1?
- No — not immediately. The 2027.1 milestone only prevents new TBA integrations from being created. Existing integrations continue until 2028.1. However, migrating before 2027.1 gives you the most time to test in sandbox without pressure.
- Do I need to rebuild my Celigo flows from scratch?
- No. The migration is connection-layer only. Your flow logic — field mappings, filters, error handling, schedules — stays intact. You update the credential configuration in the NetSuite connection, not the flows themselves.
- What is OAuth 2.0 machine-to-machine (M2M)?
- OAuth 2.0 M2M uses the client credentials grant type for server-to-server integrations. Your integration exchanges a Client ID and Client Secret for a short-lived Bearer token, which is included in the Authorization header of every API call. The token refreshes automatically before expiry.
- Does SuiteAnalytics Connect need to migrate?
- No. Oracle explicitly excluded SuiteAnalytics Connect (ODBC/JDBC) from the TBA deprecation. Those connections are unaffected by the 2027.1 and 2028.1 milestones.
Entech Solutions is a certified Celigo integration partner with deep experience in NetSuite integrations. We are tracking the TBA deprecation closely and will assist clients with credential migration when Celigo's OAuth 2.0 connector update ships. If you want to get ahead of this now — auditing connections, setting up OAuth 2.0 in sandbox, or planning your migration timeline — get in touch.