diff --git a/data/web/core.telegram.org/tdlib/getting-started.html b/data/web/core.telegram.org/tdlib/getting-started.html index fb0194f20c..d47aa2c6e0 100644 --- a/data/web/core.telegram.org/tdlib/getting-started.html +++ b/data/web/core.telegram.org/tdlib/getting-started.html @@ -86,7 +86,7 @@
  • device_model — Model of the device the Application is being run on, like “iPhone Z”.
  • After call to setTdlibParameters in case of success Application will receive updateAuthorizationState with new state and just needs to handle that update, nothing should be done explicitly. If setTdlibParameters fails, then authorization state is not changed and the Application must try to handle the current authorization state again.

    -

    The second received authorization state is always authorizationStateWaitEncryptionKey. When it is received, the database encryption key must be provided through a call to checkDatabaseEncryptionKey. For most mobile apps, you can provide an empty database encryption key here (more info). If user isn't authorized yet, then some of authorizationStateWaitPhoneNumber, authorizationStateWaitCode, authorizationStateWaitRegistration and authorizationStateWaitPassword authorization states may be received. After completing these authorization steps, the Application will receive authorizationStateReady, meaning that authorization was successful and ordinary requests can be sent now.

    +

    If user isn't authorized yet, then some of authorizationStateWaitPhoneNumber, authorizationStateWaitEmailAddress, authorizationStateWaitEmailCode, authorizationStateWaitCode, authorizationStateWaitRegistration and authorizationStateWaitPassword authorization states may be received. After completing these authorization steps, the Application will receive authorizationStateReady, meaning that authorization was successful and ordinary requests can be sent now.

    You can find complete examples of user authorization in our Java and C# examples.