The quick answer
Read the failed login's Detail before choosing a fix. For InvalidTimestamp, check the client's Unix epoch seconds against trusted time, synchronize its clock, and generate a new nonce, timestamp and signature for the next request.
This walkthrough uses a fictional Login Audit Trail row and a local signing exercise. No authentication request is sent to NetSuite, no production failure is induced, and the machine clock is unchanged. A successful local preflight is not a successful NetSuite login.
Before you start
This is troubleshooting for an existing Token-Based Authentication (TBA) integration. Use an authorized role that can inspect the Login Audit Trail. Identify the intended account, integration application, token and request time before comparing rows. Do not expose real consumer secrets or token secrets in files, screenshots or logs.
TBA uses an OAuth 1.0 signed header with HMAC-SHA256. OAuth 2.0 Bearer tokens use a different authentication model. Oracle documentation checked in October 2026 recommends OAuth 2.0 for new RESTlet and REST integrations, and states that new TBA integrations cannot be created from 2027.1. Existing TBA integrations can continue under the stated policy. This guide does not create an integration or issue credentials.
The example user is Alex Morgan, the application is Shipment Lookup Application, and the token label is Shipment Lookup Token. These names and the audit row are fictional. The native layout was compared with a dated production reference; that reference did not contain an observed InvalidTimestamp failure.
01. Include the failure detail in the audit search
Go to Setup > Users/Roles > User Management > View Login Audit Trail. Enable Use Advanced Search, then open Results.
The walkthrough removes the default columns and selects five fields to keep the result readable: Date, Status, Detail, Token-based Access Token Name and Token-based Application Name. You can retain other columns needed for your investigation. These are unsaved search settings; the walkthrough does not create a saved search.
02. Read the matching failure row
Illustration: This is a fictional audit entry; no live authentication failure was observed.
Submit the search. In the fictional result, Status Failure and Detail InvalidTimestamp appear beside the intended token and application labels. Correlate those labels and the date with the request you are investigating.
Invalid login attempt is generic. It can reflect problems with credentials, role access, signatures, nonces or other authentication settings. The timestamp diagnosis depends on the more specific detail. Some failed requests may be absent from the audit trail, so a missing row does not establish success or identify the cause.
Oracle documentation checked in October 2026 lists InvalidTimestamp when the request timestamp is outside plus or minus five minutes of server time. It recommends synchronizing clocks using NTP, sending requests soon after generating the header, and avoiding queues that leave headers stale. The source discussion reported the wording Invalid time stamp; read the detail as your account displays it rather than assuming one spelling across every context.
03. Compare a deliberately stale local timestamp
Local-only exercise. Switch to the local terminal and run:
node tba-request.mjs --skew=-600
The signing function starts from Math.floor(Date.now() / 1000) and subtracts 600 seconds. It generates a nonce and computes a real HMAC-SHA256 signature using fictional credentials and an example.invalid endpoint. It displays epoch seconds, UTC ISO time, age, nonce and signature.
The local 300-second preflight rejects the ten-minute age. That check compares with the same host clock used to generate the timestamp. It does not contact NetSuite or establish the server's current time or acceptance result.
Check the actual clock against an independent trusted time source. Correct the clock and synchronization configuration when needed. A timezone display label alone does not change correctly configured Unix time. A faulty local-time conversion can produce the wrong epoch even when the displayed wall time looks plausible. Date.now() returns milliseconds; this exercise divides by 1000 and takes the integer seconds.
04. Regenerate the complete signed request
Run the local function again without the deliberate skew:
node tba-request.mjs --skew=0
Separate requests generated within one second can have the same timestamp; the nonce must still be unique.
The result has current epoch seconds relative to this host, a different nonce, and a new signature. The full image retains the earlier request's nonce and age for comparison.
The local preflight now shows PASSED, with No HTTP request sent and Host clock unchanged still visible. This proves the local generation and age comparison only. It does not prove that the host clock matches trusted UTC, that the real credentials and permissions are valid, or that NetSuite accepted a request.
For a real retry, regenerate the complete signed header after correcting the underlying problem. Do not edit oauth_timestamp inside an already signed header. URL query parameters, including script and deploy, and OAuth parameters participate in the signature base string. Changing them requires a new signature.
The local function percent-encodes names and values, sorts the encoded parameter pairs, and excludes realm and oauth_signature from the normalized parameter set. It joins the separately encoded consumer secret and token secret with an ampersand, computes HMAC-SHA256, Base64-encodes the digest, and percent-encodes the signature for the Authorization header. Treat it as a teaching example rather than a complete production OAuth client.
Common questions
Why does the same RESTlet work from one computer but fail from another?
Compare the specific audit detail first. For InvalidTimestamp, compare actual epoch seconds, clock synchronization, request delay and timestamp generation on both machines. Also verify that their endpoint, account, token, application, role and signing inputs match. A machine-specific failure alone does not prove a timezone problem.
Does selecting the office computer's timezone fix TBA?
Not by itself. Correct Unix time is independent of its displayed timezone. The source author reported success after changing workstation time configuration, but the useful check is whether the request now contains the correct epoch seconds relative to trusted time.
Should oauth_timestamp contain milliseconds?
No. Use Unix epoch seconds for this TBA request. In JavaScript, Math.floor(Date.now() / 1000) converts milliseconds to integer seconds. Check the system clock independently; dividing an inaccurate clock value does not make it accurate.
Can I reuse the previous nonce and signature after fixing the time?
Generate a fresh nonce and timestamp, then sign the new request. The timestamp is part of the signed material. Reusing a header can retain the original timestamp or nonce problem, and changing only the timestamp breaks the existing signature.
Does PASSED in this terminal mean NetSuite accepted the request?
No. It is a local age check against the host's own clock. The exercise sends no request. A real integration still needs correct clock synchronization, credentials, account and role access, request normalization and a valid signature.
What if no failed row appears in the Login Audit Trail?
Check the account, request time, filters and integration identifiers, then inspect the client response and safe diagnostic logs. Some requests may fail before a useful audit entry is available. Absence of a row does not establish that authentication succeeded.
Does InvalidTimestamp prove the timestamp is the only problem?
No. Later authentication checks may not have been reached. After correcting time and regenerating the signed request, inspect the next actual result and audit detail.
Can I reuse production tokens in a refreshed sandbox?
Tokens are environment-specific and are not copied to a sandbox during refresh. Create the required tokens in the intended environment and verify the account endpoint.