NetSuite integration reference

The export flag NetSuite uses to track sent orders, and how NetSuite credentials (TBA) are structured.

Practical detail for the parts of a NetSuite integration that come up most often in support: the export flag NetSuite uses to track what's already been sent, and how NetSuite credentials are structured.

The export flag and duplicate orders

NetSuite integrations typically use a checkbox field on the order record to track whether it has already been exported to HC. HC ticks this field once an order has been picked up. The exact field name varies by organisation, since it's set up as part of your own integration, so check with HC if you're not sure which one applies to you.

This matters in a few situations:

  • An order isn't syncing. If the field is already ticked but the order hasn't reached its destination, HC will not pick it up again automatically. See An event hasn't arrived in the destination system for what to do.

  • You need to force a resync. Unticking the field tells HC the order is outstanding again, so it is picked up on the next run — usually only within a limited recent window, not indefinitely.

  • You're seeing duplicate orders in NetSuite. This usually means the export flag was not set correctly on an earlier order, or a related duplicate check was disabled during another change to the integration. Contact HC rather than deleting the duplicate yourself, so the underlying cause can be found and fixed.

How NetSuite credentials are structured

NetSuite integrations authenticate using token-based authentication (TBA), which has two separate credential pairs:

  • A Consumer Key and Consumer Secret, generated from the Integration record in NetSuite. NetSuite only shows the Consumer Secret once, at creation — if it's lost, a new Integration record has to be created rather than the secret being retrieved again.

  • A Token ID and Token Secret, generated separately from an access token tied to a specific role and user.

If NetSuite access is revoked or a credential expires, it's usually the Token ID/Secret that needs replacing rather than the Consumer Key/Secret. If you're not sure which one has changed, send both when you raise a ticket rather than guessing, so HC isn't going back and forth to work out which credential failed. See Providing and managing system credentials for how to send updated credentials to HC.