Tutorial August 10, 2026

How to Fix Telegram API_ID_PUBLISHED_FLOOD: A Recovery Checklist

API_ID_PUBLISHED_FLOOD means Telegram has identified the api_id used by an authorization request as published or unsuitable for released apps. Stop retrying with that credential, confirm whether your build copied Telegram’s limited sample API ID or exposed an app credential, and move the integration to an API ID created for your own application. Telegram does not document a self-service unblock or rotation endpoint for this error.

Key takeaways

Telegram explicitly says its open-source sample API ID is limited and will cause API_ID_PUBLISHED_FLOOD when used by released apps.
Telegram’s API Terms require an application to obtain its own api_id; copying another project’s pair is not a production shortcut.
API_ID_INVALID, API_ID_PUBLISHED_FLOOD, AUTH_KEY_DUPLICATED, and SESSION_REVOKED describe different failures and need different responses.
Do not print api_hash, login codes, QR tokens, or exported sessions while diagnosing the error.
A bot token is not a replacement for an API ID/API hash when the intended identity is a regular Telegram account.

How to fix Telegram API_ID_PUBLISHED_FLOOD

The error is an application-credential problem, not an instruction to wait and retry. Telegram lists it on auth.exportLoginToken as a 400 response: the API ID was published somewhere and cannot be used. Its application guide also names a common cause: open-source Telegram clients include a limited sample API ID for testing, but released apps must use their own ID.

Use this decision table before changing anything:

Observed error	What Telegram documents	Correct next action
`API_ID_PUBLISHED_FLOOD`	The API ID was published or a limited sample ID is being used beyond testing	Stop new authorization attempts; identify the credential source and replace the sample/shared credential with your application’s own pair
`API_ID_INVALID`	The `api_id` and `api_hash` combination is invalid	Check that the pair belongs together and that configuration parsing did not alter either value
`AUTH_KEY_DUPLICATED`	One authorization key was used over conflicting parallel main sessions	Generate a new authorization key and sign in again; changing the API ID alone is not the documented remedy
`SESSION_REVOKED`	The user terminated or invalidated the authorization	Start a fresh user authorization with the correct app credentials
`FLOOD_WAIT_X`	Too many attempts were made	Respect the server-provided wait; repeated retries make the situation worse

This scope is intentionally narrower than the existing API ID/API hash versus bot token comparison. That article helps choose credentials; this checklist begins after an MTProto authorization request fails.

Step 1: find where the API ID came from

Trace the value without printing the value itself. Record only a safe fingerprint, the deployment name, and the configuration source. Check:

whether a sample ID from Telegram’s open-source client code was copied into the build;
whether the same pair appears in a public repository, package, image, browser bundle, documentation snippet, issue, or CI log;
whether several products or customers share one app credential that was never intended for them; and
whether the error occurs in code login, QR login, or both.

Code and QR login both use the client application’s api_id and api_hash. QR approval changes the user interaction, not the application credential. Telegram’s auth.exportLoginToken method requires both fields and is one method that explicitly returns API_ID_PUBLISHED_FLOOD.

Step 2: obtain the correct application credentials

For a client application, sign in at my.telegram.org, open API development tools, and create or view the API ID and API hash associated with the active Telegram number. Telegram currently states that each number can have only one API ID.

That one-ID-per-number limit matters: do not promise an instant rotation workflow that Telegram does not document. If the failed value was merely Telegram’s sample or another project’s credential, replacing it with your own application pair is the clear official path. If your own API ID was publicly exposed and is now rejected, remove the exposure, preserve non-secret evidence, and use Telegram’s official support path for account-specific remediation rather than guessing that retries will clear the state.

Keep the api_hash server-side. Inject it from a credential store at runtime, prevent it from reaching client bundles, and mask it in logs and error trackers. Treat QR login tokens, verification codes, 2FA material, and authorized session exports as separate secrets with shorter lifetimes.

Step 3: migrate without creating a second incident

Use a controlled rollout:

Freeze new login attempts that use the rejected ID.
Update the application credential reference in one test environment; do not paste the secret into source code.
Start one fresh code or QR authorization and capture the error type, request stage, and timestamp without sensitive values.
If authorization succeeds, verify the resulting account identity before enabling traffic.
Roll out gradually and watch for FLOOD_WAIT_X, SESSION_REVOKED, and unexpected duplicate-session errors.
Remove the old credential reference from deploy manifests, examples, cached CI artifacts, and support runbooks.

Do not reuse an exported session as proof that the underlying application credential is healthy. A session and an API ID solve different parts of authorization, and an old authorized session does not validate a new login path.

Where UnifyPort fits

UnifyPort’s regular Telegram account flow uses the same application boundary. Code authorization requires provider_data.api_id, provider_data.api_hash, and provider_data.phone; QR authorization still requires the API ID and API hash. The Telegram authorization guide documents the exact code, QR, 2FA, and session steps.

If Telegram rejects the application credential, UnifyPort cannot make that credential valid, create a Telegram API ID for you, or convert a BotFather token into a regular-account session. Resolve the Telegram credential first, then restart the relevant authorization flow.

After the account is authorized, inbound messages can be delivered as normalized message.received events. The Telegram-to-Slack relay build guide shows the downstream webhook workflow, which should remain separate from credential recovery.

Limitations and trade-offs

Use the official Bot API when a separate bot identity is acceptable. A bot token is purpose-built for that model and avoids a user-account login, but it cannot act as an existing regular account.

Use an MTProto user-account flow only when the product genuinely requires that identity. It creates sensitive session material and remains subject to Telegram’s API Terms and automated abuse controls. An unofficial interface does not remove those rules, guarantee restoration of a rejected API ID, or authorize bulk unsolicited messaging.

FAQ

What causes Telegram API_ID_PUBLISHED_FLOOD?

Telegram documents two closely related signals: auth.exportLoginToken returns the error when an API ID was published somewhere, and Telegram’s application guide says using its limited sample API ID in a released app triggers the error for users.

Can I fix API_ID_PUBLISHED_FLOOD by waiting?

Telegram does not describe it as a timed FLOOD_WAIT_X condition and does not publish a self-service unblock duration. Stop retries, replace a sample or borrowed credential with your own application pair, and seek official remediation if your own ID was exposed.

Is API_ID_INVALID the same error?

No. API_ID_INVALID means the API ID/API hash combination is invalid. API_ID_PUBLISHED_FLOOD means the ID has been identified as published or unsuitable for the attempted use. Check the exact error type before changing sessions or credentials.

Can a BotFather token replace the rejected API ID?

Not for regular-account authorization. A bot token authenticates a bot to the Bot API. Code and QR login for an existing user account still require an application API ID and API hash.

Should I log the API hash to compare environments?

No. Compare a one-way fingerprint or secret version identifier instead. Keep the API hash, login codes, QR tokens, 2FA material, and session exports out of logs, tickets, screenshots, and public examples.

Next step

Use Telegram’s official application setup guide to confirm that the integration uses its own API ID. After correcting the credential source, follow the UnifyPort Telegram authorization guide for one controlled code or QR authorization.

Sources

Sources and product documentation verified on 2026-08-10.