<divclass="dev_page_bread_crumbs"><ulclass="breadcrumb clearfix"><li><ahref="/api">API</a></li><iclass="icon icon-breadcrumb-divider"></i><li><ahref="/api/invoking">Calling API Methods</a></li></ul></div>
<p>Versioning in the API is supported by so-called TL layers.</p>
<p>The need to add a new object constructor or to add/remove a field in a constructor creates a backwards compatibility problem for previous versions of API clients. After all, simply changing a constructor in a schema also changes its number. To address this problem, each schema update is separated into a layer.</p>
<p>A layer is a collection of updated methods or constructors in a TL schema. Each layer is numbered with sequentially increasing numbers starting with 2. The first layer is the base layer -- the TL schema without any changes.</p>
<p>There is a helper method to let the API know that a client supports the Layer <code>layer</code>:</p>
<p>The helper method <strong><ahref="/method/invokeWithLayer">invokeWithLayer</a></strong> can be used only together with <ahref="/method/initConnection">initConnection</a>: the present layer will be saved with all other parameters of the client and any future requests will be using this saved value. <ahref="#saving-client-info">See more below</a>.</p>
<h4><aclass="anchor"href="#list-of-available-layers"id="list-of-available-layers"name="list-of-available-layers"><iclass="anchor-icon"></i></a><ahref="/api/layers">List of Available Layers</a></h4>
<p>It is possible to save information about the current client on the server in conjunction with an authorization key. This may help eliminate client-side problems with certain releases on certain devices or with certain localizations, as well as eliminate the need for sending layer information in each request.</p>
<p>The helper method <strong><ahref="/method/initConnection">initConnection</a></strong> accepts client parameters. This method must be called when first calling the API after the application has restarted or in case the value of one of the parameters could have changed.</p>
<p><strong>initConnection</strong> must also be called after each <ahref="/method/auth.bindTempAuthKey">auth.bindTempAuthKey</a>.</p>
<p>When calling this method, the current layer used by the client is also saved (the layer in which <ahref="/method/initConnection">initConnection</a> was wrapped is used). After a successful call to <ahref="/method/initConnection">initConnection</a> it is no longer necessary to wrap each API call in <strong>invokeWithLayerN</strong>.</p>
<p><ahref="/method/invokeWithoutUpdates">invokeWithoutUpdates</a> can be used to invoke a request without subscribing the used connection for <ahref="/api/updates">updates</a> (this is enabled by default for <ahref="/api/files">file queries</a>).</p>
<p>By default, the server processes parallel requests in arbitrary order. Two helper methods exist for cases when the client needs certain requests to be processed in a certain order and intends to send a new request before the previous one is completed.<br>
These methods allow reducing the latency for calls which require strict ordering, since the client doesn't have to wait for the result of the previous method call before sending the next one in the queue, and can just send them all together, (for example) each wrapped in an <code>invokeAfterMsg</code> with the <code>msg_id</code> of the previous request. </p>
<p>They may be used, for example, when a client attempts to send messages that accumulated while waiting for the Internet connection to be restored for a long time. In this case, the 32-bit number <code>0xcb9f372d</code> must be added before the method number in each request, followed by a 64-bit message identifier, msg_id, which contains the previous request in the queue. </p>
<p>The second method is similar, except it takes several messages that must be successfully processed before the current one.</p>
<p>If the waiting period exceeds 0.5 seconds (this value may change in the future) and no result has appeared, the method will return the <code>MSG_WAIT_TIMEOUT</code> error: handle this error by resending the request, still wrapped in the same <code>invokeAfterMsg</code>/<code>invokeAfterMsgs</code> constructor with the same <code>id</code>/<code>ids</code>. </p>
<p>If any of the previous queries mentioned in <code>msg_ids</code> or <code>msg_id</code> fails (i.e. an RPC error is emitted by a query, including <code>FLOOD_WAIT_</code> errors), a <code>MSG_WAIT_FAILED</code> error will be returned for the current request: the simplest way to handle it is to simply enforce local synchronization, by waiting for a response from all previous <code>msg_ids</code>/<code>msg_id</code> before resending the request. </p>
<p>If and only if any of the previous requests also failed with <code>MSG_WAIT_FAILED</code>/<code>MSG_WAIT_TIMEOUT</code> errors and require resending, wrap the current request in another <code>invokeAfterMsg</code>/<code>invokeAfterMsgs</code> constructor with the new IDs of the previous requests, resent along with the current one. </p>
<p>If the first messages.sendMessage query with <code>msg_id=1</code> fails, both queries with <code>msg_id=2</code> and <code>msg_id=3</code> will fail with a <code>MSG_WAIT_FAILED</code> and will have to be resent as follows.<br>
To recover the call queue, send the following new sequence of queries:</p>
<ol>
<li>msg_id=4; <code>messages.sendMessage message=b</code> (resending the old query with <code>msg_id=2</code>)</li>
<li>msg_id=5; <code>invokeAfterMsg msg_id=4 (messages.sendMessage message=c)</code> (resending the old query with <code>msg_id=3</code>)</li>
<p>If the first messages.sendMessage query with <code>msg_id=1</code> succeeds but the second with <code>msg_id=2</code> fails, the query with <code>msg_id=3</code> will fail with a <code>MSG_WAIT_FAILED</code> and will have to be resent as follows.<br>
To recover the call queue, send the following new sequence of queries:</p>
<ol>
<li>msg_id=4; <code>messages.sendMessage message=c</code> (resending the old query with <code>msg_id=3</code>)</li>
<p>If either or both of the messages.sendMessage queries with <code>msg_id=1</code> and/or <code>msg_id=2</code> fail, the query with <code>msg_id=3</code> will also fail with a <code>MSG_WAIT_FAILED</code> and will have to be resent as follows. </p>
<p>To recover the call queue, first of all wait for a response from the queries with <code>msg_id=1</code> and <code>msg_id=2</code>. </p>
<p>Note how this is different from scenario 1, where we don't have to wait for a response from the previous queries: this is because in scenario 1, each <code>invokeAfterMsg</code> query was directly waiting for just one previous query, and any new query in the queue is chained to the previous <code>invokeAfterMsg</code>, thus any failure of any query with <code>msg_id=N</code> in the chain immediately blocked execution of all queries with <code>msg_id <= N</code>.<br>
In this case, however, we're waiting for two messages at the same time, and the failure of the query with <code>msg_id=1</code> does not prevent execution of the query with <code>msg_id=2</code>, and vice versa; thus when resending the query with <code>msg_id=3</code> we have to either:</p>
<ul>
<li>
<p>Wait for replies (errors or successes) for <strong>all</strong> of the queries mentioned in <code>msg_ids</code>, and then send the following new query: </p>
<ul>
<li>msg_id=4; <code>messages.sendMessage message=c</code> (resending the old query with <code>msg_id=3</code>)</li>
</ul>
</li>
<li>
<p>OR Wait for the receival of an RPC error for any of the queries mentioned in <code>msg_ids</code>, and then send the following new query:</p>
<ul>
<li>msg_id=4; <code>invokeAfterMsgs msg_ids=([1, 2] - [$errId]) (messages.sendMessage message=c)</code> (resending the old query with <code>msg_id=3</code>)</li>
</ul>
<p>I.e. resend the <code>invokeAfterMsgs</code> with all the initial <code>msg_ids</code> except for the one that failed.<br>
It may be required to repeat the process if the newly sent <code>invokeAfterMsgs</code> also fails because the remaining query mentioned in <code>msg_ids</code> also failed (i.e. if queries <code>1</code> and <code>2</code> both fail at slightly different times). </p>
<p>Obviously the first option (waiting for replies (errors or successes) for <strong>all</strong> of the queries mentioned before proceeding) is the simplest.</p>
</li>
</ul>
<p>An even simpler option is to always follow <ahref="#scenario-1">Scenario 1</a>, never using <code>invokeAfterMsgs</code> and only using chained <code>invokeAfterMsg</code> calls, thus avoiding the use of this slightly more complicated recovery logic.</p>
<p><strong>Important:</strong> if the helper methods <strong>invokeAfterMsg</strong> / <strong>invokeAfterMsgs</strong> are used together with <strong>invokeWithLayerN</strong> or other helper methods, <strong>invokeAfterMsg</strong> / <strong>invokeAfterMsgs</strong> must always be the outermost wrapper.</p>
<p>We recommend using gzip compression when calling methods to reduce the amount of network traffic.</p>
<p>The schema and constructor information are given in the <ahref="/mtproto/service_messages#packed-object">protocol documentation</a>.</p>
<h4><aclass="anchor"href="#data-compression-when-making-a-request"id="data-compression-when-making-a-request"name="data-compression-when-making-a-request"><iclass="anchor-icon"></i></a>Data Compression when Making a Request</h4>
<p>Before transmitting a query, the string containing the entire body of the serialized high-level query (starting with the method number) must be compressed using gzip. If the resulting string is smaller than the original, it makes sense to transmit the <ahref="/mtproto/service_messages#packed-object">gzip_packed</a> constructor.</p>
<p>By default, the server compresses the response to any request as well as <ahref="/api/updates">updates</a>, in accordance with the rules stated above. If the <ahref="/mtproto/service_messages#packed-object">gzip_packed</a> constructor is received as a response in rpc_result, then the string that follows must be extracted and uncompressed. Processing then continues on the resulting new string.</p></div>
</div>
</div>
</div>
<divclass="footer_wrap">
<divclass="footer_columns_wrap footer_desktop">
<divclass="footer_column footer_column_telegram">
<h5>Telegram</h5>
<divclass="footer_telegram_description"></div>
Telegram is a cloud-based mobile and desktop messaging app with a focus on security and speed.
