Contacting support

How requests are prioritised, and what never to send

Priority follows impact and urgency, not wording. And no request should ever carry a password, an access token, an API secret, an Authorization header or a private QR payload — not in the message, not in a screenshot, not in an attached log.

Reviewed August 20, 2026

Steps

1. State how many people and which codes are affected, and whether a workaround exists. That is what sets the order.
2. Expect critical first — a platform-wide failure, a risk of losing data, or a security issue — then a core function unusable for a whole workspace with no workaround, then defects that have one, then how-to questions.
3. Mask every secret before attaching anything, screenshots included.
4. If a secret has already left your hands, revoke and rotate the key first. That closes the exposure; deleting the message does not.
5. Report a suspected vulnerability with “security” in the subject, without a working exploit, and keep the details private until it is fixed.

How to check it worked

Nothing you are about to send would be dangerous if it were forwarded to the wrong address, and the impact is stated in numbers rather than adjectives.

What usually goes wrong

• Marking everything urgent, which stops meaning anything.
• An Authorization header visible in a pasted terminal log.
• Asking for a message to be deleted instead of rotating the leaked key.