Diagnose a failing request

Source: https://docs.luxid.lu/en/developers/troubleshooting/diagnose/

Last updated: 2026-07-03

When your integration returns errors, work through the decision tree below before raising a support ticket. Most integration issues come down to an environment or Client ID mismatch, or a deterministic OAuth error that a retry will not fix.

Decision tree

flowchart TD
    accTitle: Diagnosing a failing LuxID request
    accDescr: A decision tree that first confirms the correct environment base URL and Client ID for UAT or Production, then checks whether the error carries an OAuth error code pointing to the error-code reference, and otherwise guides you to capture an on-screen identifier - enabling debug logging if needed - before raising a support ticket with the identifier, application name, timestamp, and error.
    A[You are seeing errors] --> B{Which environment?}
    B -->|UAT| C["Check UAT base URL:<br>login-uat.luxid.lu"]
    B -->|Production| D["Check Prod base URL:<br>login.luxid.lu"]
    C --> E{"Are you using the<br>correct Client ID<br>for UAT?"}
    D --> F{"Are you using the<br>correct Client ID<br>for Production?"}
    E -->|No| G["Update Client ID<br>to UAT credentials"]
    F -->|No| H["Update Client ID<br>to Production credentials"]
    E -->|Yes| I{"Does the error<br>have an OAuth<br>error code?"}
    F -->|Yes| I
    I -->|Yes| J["See OAuth and OIDC<br>error codes"]
    I -->|No| K{"Do you have an<br>on-screen identifier<br>from the error?"}
    J --> L{Resolved?}
    L -->|Yes| M[Done]
    L -->|No| K
    K -->|No| N["Enable debug logging<br>and reproduce the error<br>to capture an identifier"]
    K -->|Yes| O["Raise a ticket at<br>servicedesk@post.lu<br>with the identifier,<br>Application name,<br>timestamp, and error"]
    N --> O

Which on-screen identifier you capture depends on the screen the user saw. See the identifiers reference for the full model; the short version is below.

How to find the right identifier

Two different LuxID screens carry two different identifiers, and quoting the wrong one to support wastes a round-trip:

• Authentication error dialog ("Connection error with LuxID") - a failed sign-in transaction. It shows an Error ID (a short symbolic scenario code, e.g. login) and a long-hex Transaction ID. Quote both; the Transaction ID is the handle LuxID uses to find the authentication log entry.
• WAF block / masked-500 page - a request blocked or masked at LuxID's edge. LuxID's Web Application Firewall (WAF) returns a Support ID, a generic reference. Quote it so the team can trace the corresponding edge logs.

Copy the identifier exactly when you raise a ticket.

Neither of those is the Global Transaction ID

LuxID also carries an internal Global Transaction ID in the HTTP response headers, not on any screen. Your own code can capture it automatically from responses; the user never sees it. Include it in a ticket if you have it, but the on-screen Transaction ID or Support ID is what the user can quote. See the identifiers reference.

Raising a ticket

If you have worked through the decision tree and still cannot identify the cause, raise a ticket with LuxID. Include the environment, your Application name and Client ID, the on-screen identifier (Transaction ID for a failed sign-in, Support ID for a WAF block / masked-500), a timestamp window, the full error response, the reproduction steps, and the expected behaviour. The more detail you provide up front, the faster the team can correlate your report with server-side traces.

For the full ticket template and support contact options, see Contact and support channels.