Interfaces & APIs
API authentication failed: 401 or 403?
HTTP 401 indicates missing or rejected authentication. HTTP 403 means the request is refused, often because the required permissions are missing. The API documentation and response text show which rules the specific interface uses.
- SourceIntegration application
- Check the connectionIdentity & Permissions
- DestinationAPI resource
How this appears in daily operation
A scheduled synchronization worked yesterday. Today it receives only 401 or 403. An administrator can still log in through the interface. These are different access methods: a working browser account does not confirm access for the integration application.
Distinguish typical causes
Access no longer valid
A token may have expired, been replaced or been revoked. The interface determines whether a renewal mechanism is available.
Missing access to the resource
Authentication may be valid while the account, role or approved scope does not match the requested function.
Different environment or request
Test and production systems may use separate accounts and addresses. A changed request may also access a different area.
What you can check first
Record status and response text separately
Record the time, resource and any request ID. Remove secrets from headers or URLs.
Review the last change with those responsible
Was a key rotated, a role changed or the application moved to another environment?
Review documentation and approvals
Check the expected authentication method and required permissions. Do not repeat production write requests as a connection test.
When the problem runs deeper
Repeated authentication problems may indicate unclear responsibilities or a missing renewal process. We therefore examine not just the current key, but also the planned data flow and its feedback. The goal is traceable access with appropriate permissions.
Distinguish authentication from authorization
First, we clarify which identity the application uses. Then we determine whether it may perform the desired function. A new token with the same unsuitable permissions may not fix the error.
Make process failures visible
A failed retrieval must not be processed as an empty dataset. We clarify when a run stops, when a retry makes sense and who receives understandable feedback. These rules follow your process.
When support makes sense
If synchronization is operationally important or multiple systems are involved, clear access and process planning is worthwhile. The API name, status code and an anonymized description are enough for the first discussion. API keys are not needed.
The right solution pathConnect interfaces with clearly defined accessSources for technical assessment
Technical content reviewed on 7 October 2026. Vendor statements refer to the products named; they do not replace checking your specific configuration.
Clarify the next step together.
Your application names and a brief description of the problem are enough to start.
