Record a non-sensitive error code and time, then investigate its category. One code can have more than one cause.
-2015 is not only a wrong key
The official definition covers API key, IP or action permissions. Check the account and environment first, then key validity, the tool’s actual outbound IP and the permission needed for that operation. If a tool only reports “connection failed,” ask its support team for a redacted error category.
-1021 and -1022: time versus signature
-1021 points to request timestamp acceptance issues. Check the clock on the server running the tool, not merely your browser’s displayed time. -1022 means the signature is invalid: the maintainer should review the algorithm, matching credentials and parameter encoding. Do not paste fully signed requests into public tickets.
429: stop retrying and review frequency
HTTP 429 signals rate limiting. Respect Retry-After, reduce polling and coordinate other programs sharing the outbound IP. Switching keys is not a reliable answer to IP-based limits. Repeated violations can lead to an IP ban.
What to give support
Provide the code, UTC time, tool version, intended function, test-versus-production environment and redacted reproduction steps. Remove keys, signatures, account identifiers and private financial records. Our error selector suggests checks; it does not investigate your actual requests.
Locate the failure before changing access
A page that will not open, a tool that cannot send a request and a rejected platform request are different observations. Identify the last completed step: login, saving settings, beginning synchronization or receiving a response. If the provider supplies only an internal number, ask which layer and function it describes.
Keep a timeline of the last known working check, recent changes and the first observed failure. Mark the time zone. A server move is a useful lead, not proof of the cause. Describe whether the issue is constant or limited to one feature rather than calling the entire account broken.
Put each investigation with the right owner
Check the actual connection and environment before editing settings. Similar labels and old configurations can lead you to change the wrong object. For a hosted tool, the provider may control the machine that creates requests; changing your phone’s time does not establish that its server clock changed.
A non-developer can confirm the documented connection method and provide redacted steps. Signature implementation belongs with the software maintainer. Do not run a stranger’s diagnostic script or reveal credentials merely to make a report more detailed. Increasing account permissions does not resolve a timestamp or signature explanation.
Make the report useful without reproducing the account
Describe expected and observed behavior, version, environment, UTC time, recent changes and one low-risk reproduction sequence. Remove secrets, signatures, private records and account identifiers. Inspect attachments, filenames and the address bar as well as the error text.
For a rate-limit response, do not keep generating requests through repeated connection attempts. Ask how the tool stops automatic retries and whether other tasks share resources. Restoring one necessary function is easier to observe than restarting everything together. Use the detailed rate-limit guide for implementation questions.
Know when to stop and what recovery proves
Pause changes if the active connection is unclear, no useful error is available or a proposed fix asks for unexplained access. If credentials may be exposed, prioritize affected access and official guidance rather than preserving them for reproduction.
After a successful check, record the exact change and verified scope. One read operation is not evidence that every task has recovered. Remove unnecessary diagnostic material and revisit temporary configuration changes. A provider’s release note may explain a fix, but your own environment still needs an appropriately scoped check. Unverified areas can remain explicitly unresolved.