Keep webhook credentials out of a desk display
Status Light can show a small summary of software activity through a custom integration. Its display does not need webhook secrets, API tokens or raw event payloads to indicate that work needs attention. Keep authentication in the receiver and bridge components that require it, and pass only the derived state needed by the hardware and companion status view.
Where should incoming events be authenticated?
Validate the request at the receiving boundary using the source's documented mechanism. For GitHub, consult the webhook delivery-validation instructions. Confirm that the handler checks authenticity before allowing the event to influence the selected task state.
Do not confuse a task identifier with a credential. Identifiers can help route events but do not generally establish who sent them. Keep rejection reasons useful for diagnosis without returning or recording the secret value used in validation.
What should be excluded from URLs and logs?
Avoid embedding secret values in webhook destination URLs or diagnostic links. URLs can appear in server logs, browser history and screenshots. Use the authentication mechanism supported by the actual service instead of inventing a token-bearing address for convenience.
Inspect logging around headers, payloads and errors. A failed request can expose more data than a successful one if an exception handler prints everything it received. Record the relevant event identity and validation outcome while omitting credentials and unrelated private content.
What information should reach the display layer?
Convert a validated event into a narrow state record, such as the selected task reference, interpreted outcome and freshness. The physical device needs only its supported command, while a companion view may need a safe link back to the source. Neither needs the original authentication secret.
Review task names before showing them in a shared room. Even without credentials, a project label can reveal information that colleagues or visitors do not need. A generic attention cue may be enough when detailed context remains available in the authorised source interface.
How should the arrangement be checked?
Use non-sensitive fixtures to inspect successful handling, invalid authentication and error logging. Confirm that a rejected event cannot update the lamp and that diagnostic output does not reveal the test secret. Check configuration files and any screenshots prepared for support before sharing them.
Follow the source's normal credential-management process when a secret needs replacement. The Status Light product page describes the physical indicator; keeping credentials out of notifications is a responsibility of the integration that receives, interprets and displays the source's events.