InlineQueryHandler

.. autoclass:: InlineQueryHandler

:members:

Pyrogram's API, which consists of well documented convenience methods_ and facade types_, exists to provide a much

easier interface to the undocumented and often confusing Telegram API.

In this section, you'll be shown the alternative way of communicating with Telegram using Pyrogram: the main "raw"

Telegram API with its functions and types.

Telegram API, you have to use the raw :mod:`functions <pyrogram.api.functions>` and :mod:`types <pyrogram.api.types>`.

As already hinted, raw functions and types can be really confusing, mainly because people don't realize soon enough they

accept *only* the right types and that all required parameters must be filled in. This section will therefore explain

some pitfalls to take into consideration when working with the raw API.

Every available high-level methods in Pyrogram is built on top of these raw functions.

re-implemented by providing a much simpler and cleaner interface which is very similar to the Bot API (yet much more

powerful).

Invoking Functions

Unlike the methods_ found in Pyrogram's API, which can be called in the usual simple way, functions to be invoked from

the raw Telegram API have a different way of usage and are more complex.

First of all, both `raw functions`_ and `raw types`_ live in their respective packages (and sub-packages):

``pyrogram.api.functions``, ``pyrogram.api.types``. They all exist as Python classes, meaning you need to create an

instance of each every time you need them and fill them in with the correct values using named arguments.

Next, to actually invoke the raw function you have to use the :meth:`send() <pyrogram.Client.send>` method provided by

the Client class and pass the function object you created.

Here's some examples:

- Disable links to your account when someone forwards your messages:

Chat IDs

The way Telegram works makes it impossible to directly send a message to a user or a chat by using their IDs only.

Instead, a pair of ``id`` and ``access_hash`` wrapped in a so called ``InputPeer`` is always needed. Pyrogram allows

sending messages with IDs only thanks to cached access hashes.

There are three different InputPeer types, one for each kind of Telegram entity.

Whenever an InputPeer is needed you must pass one of these:

- `InputPeerUser <https://docs.pyrogram.ml/types/InputPeerUser>`_ - Users

- `InputPeerChat <https://docs.pyrogram.ml/types/InputPeerChat>`_ - Basic Chats

- `InputPeerChannel <https://docs.pyrogram.ml/types/InputPeerChannel>`_ - Either Channels or Supergroups

But you don't necessarily have to manually instantiate each object because, luckily for you, Pyrogram already provides

:meth:`resolve_peer() <pyrogram.Client.resolve_peer>` as a convenience utility method that returns the correct InputPeer

by accepting a peer ID only.

Another thing to take into consideration about chat IDs is the way they are represented: they are all integers and

all positive within their respective raw types.

Things are different when working with Pyrogram's API because having them in the same space can theoretically lead to

collisions, and that's why Pyrogram (as well as the official Bot API) uses a slightly different representation for each

kind of ID.

For example, given the ID *123456789*, here's how Pyrogram can tell entities apart:

- ``+ID`` User: *123456789*

- ``-ID`` Chat: *-123456789*

- ``-100ID`` Channel (and Supergroup): *-100123456789*

So, every time you take a raw ID, make sure to translate it into the correct ID when you want to use it with an

high-level method.

.. _methods: ../pyrogram/Client.html#messages

.. _types: ../pyrogram/Types.html

.. _raw functions: ../pyrogram/functions

.. _raw types: ../pyrogram/types

As already mentioned in previous sections, Pyrogram can be configured by the use of an INI file.

The idea behind using a configuration file is to help keeping your code free of private settings information such as

The ``[pyrogram]`` section contains your Telegram API credentials: *api_id* and *api_hash*.

As you may probably know, Telegram allows users (and bots) having more than one session (authorizations) registered

app (or by invoking `GetAuthorizations <../functions/account/GetAuthorizations.html>`_ with Pyrogram). They store some

useful information such as the client who's using them and from which country and IP address.

**A Pyrogram session running on Linux, Python 3.6.**

(which are in turn children of the :obj:`RPCError <pyrogram.RPCError>` superclass):

Here we'll show some advanced usages when working with `update handlers`_ and `filters`_.

If you register handlers with overlapping (conflicting) filters, only the first one is executed and any other handler

will be ignored. This is intended by design.

In order to handle the very same update more than once, you have to register your handler in a different dispatching

group. Dispatching groups hold one or more handlers and are processed sequentially, they are identified by a number

(number 0 being the default) and sorted, that is, a lower group number has a higher priority:

For example, take these two handlers:

Here, ``just_text`` is never executed because ``text_or_sticker``, which has been registered first, already handles

texts (``Filters.text`` is shared and conflicting). To enable it, register the function using a different group:

**the same group** regardless of the next handler's filters. This allows you to register multiple handlers with

overlapping filters in the same group; to let the dispatcher process the next handler you can do *one* of the following

in each handler you want to grant permission to continue:

.. _`update handlers`: UpdateHandling.html

.. _`filters`: UsingFilters.html