Quick answer: The GetTGAPI public API base URL is
https://gettgapi.com/api/open/v1. Call it from your server using an access code as a Bearer key. A complete flow checks the balance, creates an application, submits the current verification code, retrieves the result and deletes the temporary result after saving it. HTTP 202 means accepted, not completed.
Check which API you need
The GetTGAPI API integrates our application assistance service into your system. Its result is the Telegram API ID and API Hash associated with the verified number. It is not the Telegram Bot API and does not provide new Telegram account registration, client login or chat reading.
Verification still requires participation by someone authorized to use the account. Your interface must display the current request status and let that person provide the developer portal verification code. An integration does not remove verification requirements.
This guide explains the sequence and common integration mistakes. For field definitions, errors and complete request and response formats, use the GetTGAPI developer reference, OpenAPI specification and Python example.
Keep the access code on your server
Business requests use these headers. The value below is a placeholder:
Authorization: Bearer YOUR_AUTHORIZATION_CODE
Accept: application/json
Write requests also need Content-Type: application/json and their own Idempotency-Key. Never put the access code in a URL, browser JavaScript, public repository or request log. Your frontend should call your backend, which then authenticates to GetTGAPI.
GET /balance checks the balance without consuming a credit. Website and API requests share the same code's balance, with at most two reserved applications per code. A balance snapshot does not guarantee a later request will be accepted: another concurrent request may use an available credit first.
The complete flow: acceptance, verification, delivery and deletion
| Step | Request and action |
|---|---|
| Check balance | GET /balance; inspect available and reserved |
| Create application | POST /applications with phone, title, short_name and consent; save the returned id |
| Wait for verification | GET /applications/{id} at the returned poll_after_seconds interval; do not create duplicates |
| Submit the code | Only in waiting_code with a non-null challenge, send the current challenge_id and code to POST /applications/{id}/code |
| Retrieve result | Once status is succeeded, promptly call GET /applications/{id}/result |
| Confirm deletion | After reliably saving the result in your system, call POST /applications/{id}/result/deletion with confirm: true |
Allow at least 5 seconds between normal progress queries and follow the returned interval. poll_after_seconds=0 means automatic querying should stop. Once the user submits a code, wait for processing rather than asking for the old challenge again.
Why a timeout should not trigger another application
A client timeout means you did not receive the response. It does not prove that the server rejected the request. Generate and persist the idempotency key before the first write; retry the same operation with the same key and identical parameters after a network failure.
Once you have an application id, query that application instead of creating another with a new key. Creating an application, submitting a code and deleting a result are separate operations and must not share a key. A different verification challenge also needs a new operation key.
Changing keys cannot force duplicate consumption or recover a deleted result for the same number under a code. The API list contains only records created through the API with that access code; it is not a browser-history retrieval endpoint.
Turn exceptional states into a clear next step
waiting_code: ask for a code only if a valid challenge exists. If it is absent, do not submit an expired code; follow the reference for cancellation and a new application.retry_wait: the server is waiting or retrying automatically. Check retry_at; your integration should not restart the same operation.review_required: stop automatic polling, retain the application id and request_id, and contact GetTGAPI support.failedorcancelled: the request has ended. Check the updated balance for released credits. Generate a new operation key only if a new application is actually needed.deleted: the temporary result has been cleared. This is not a retryable network failure.
Do not collapse accepted, verification in progress, code received by the user and result obtained into one success message. Show the state actually returned. Whether a verification message reached the user must be confirmed by the user.
Saving and deletion are part of the integration
Temporary results are retained for at most 1800 seconds. Retrieve them promptly on success, check result_expires_at, and deliver or store them securely. Do not defer retrieval until a later scheduled job, and do not delete before verifying that saving succeeded.
After confirmed deletion, reading the result should return the cleared-result response, HTTP 410. This means our temporary result is no longer retrievable. Copies in your own database, logs or customers' devices remain your system's responsibility.
GetTGAPI cannot reissue deleted results. Whether delivery is automated or manual, call deletion only after you can confirm the result has been saved.
What to verify before launch
Cover idempotent retries after timeouts, changed verification challenges, insufficient credits, uncertain outcomes, result expiry and reads after deletion. Use accounts and access codes you are authorized to use. A 202 response alone does not demonstrate that a real application completed.
Start with the complete API reference. To try the service manually, visit the GetTGAPI homepage or access code entry. For ambiguous states, give support redacted error details and tracing identifiers.