Identify the layer before interpreting ERROR
A webpage displaying ERROR is not enough to diagnose Telegram RPC throttling. Establish whether the failure belongs to a browser request, developer-portal page, client RPC call or GetTGAPI task. Similar words and numbers can appear at different layers.
This is a concise reading guide with our diagnostic method, not a complete error dictionary. For portal applications, start with my.telegram.org ERROR.
Reading the official RPC reference
The official error reference distinguishes numeric code from optional string type. Categories include 303 for data-center migration, 400 for input errors, 401 for unauthorized use, 403 for privacy/permission restrictions, 420 for frequency limits and 500 for internal errors. X in FLOOD_WAIT_X is a wait in seconds. Consult the original and official error database for method-specific errors; these are not a one-to-one mapping to webpage HTTP statuses.
GetTGAPI’s diagnostic sequence
The following is our engineering advice, separate from the official classification above.
- Locate the page and action. Distinguish requesting a portal code, submitting it and creating an application. “Failed” alone is insufficient.
- Establish whether the response is definite. Review the page prompt, HTTP response and management log separately. A timeout means an uncertain outcome, not necessarily official rejection.
- Check the result before retrying. Creation may have succeeded while result retrieval failed. Look for an existing application before submitting another create operation.
- Separate diagnostics from customer guidance. Keep sanitized detail available to administrators, while giving customers understandable causes and next actions without internal connection settings or secrets.
A reusable diagnostic record
This is an example evidence structure, not Telegram’s response format or a real customer log:
{
"stage": "read_application_result",
"source": "portal_parser",
"upstream_error_type": null,
"outcome": "needs_result_check",
"next_action": "verify_existing_application"
}
Keep an unknown official error type null. Do not invent a throttling label from a generic ERROR. Times and attempt counts help investigation; verification codes, API Hash, cookies and session files must not be recorded in diagnostic logs.
Result parsing can resemble a queue delay
During GetTGAPI maintenance, a portal compatibility issue left the visible Hash masked. The parser missed the actual value and kept reconciling the result. This illustrates why creation, result parsing and queue progress need separate verification. “Processing” alone does not establish either an upstream refusal or queue congestion.
This is a maintenance observation, not the cause of every long-running task. Follow an explicit upstream wait when one exists. Otherwise verify the evidence rather than inventing a countdown.
Describe the issue to support
Provide the page, step, time and a prompt without secrets. Support at gettgapi.com/en/help#contact assists with API ID / Hash applications. For errors inside your own client, read API_ID_INVALID or FLOOD_WAIT, and distinguish application configuration from portal creation.