How API Authentication Works: API Key, Bearer and OAuth
Why an integration returns 401 when the credentials look correct — and the difference between a token you paste into a header and a signature recomputed on every request.
A server needs two things before it will serve a request: who is asking (authentication) and whether they are allowed (authorization). The two get confused constantly when reading errors, yet they are fixed in completely different places: one is about credentials, the other about roles and permissions.
API Key
The simplest form: one secret string attached to a header or query parameter. Easy to use, but anyone holding it can impersonate you, and it usually never expires. Reasonable for low-risk internal services.
Bearer Token
The token travels in the Authorization header behind the word Bearer. It normally has a short lifetime and must be renewed with a refresh token. If an integration suddenly dies after working fine, an expired token is the first suspect.
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...OAuth 1.0a — what NetSuite TBA uses
Unlike Bearer, OAuth 1.0a sends no secret at all. What it sends is a signature computed from the method, the URL, the parameters, the consumer secret and the token secret combined. The signature therefore differs on every request — copying an Authorization header from another request will always fail.
- Consumer Key and Secret — identify the calling application or integration.
- Token ID and Secret — identify the user and role being used.
- Realm — the NetSuite Account ID, including the _SB1 suffix for Sandbox.
- Timestamp and Nonce — recomputed per request so a captured call cannot be replayed.
When you get a 401, check in this order
- 01The realm / account ID is right, Sandbox suffix included — this is the most frequent cause by a wide margin.
- 02The method and URL match exactly what was signed, query parameter order included.
- 03The machine clock is not badly skewed. A timestamp too far off is rejected.
- 04The token has not been revoked and the role attached to it is still active.
- 05If everything is correct but only certain endpoints are refused, that is no longer a 401 problem — it is a permission problem (403).