Peers and access_hash: Why an ID Alone Can't Send

Peers: whoever you exchange messages with

In the Telegram API, anything you send messages to or ask about, whether a user, a group or a channel, is called a peer. In the Bot API a numeric chat_id was enough (see reading chat IDs), but in the user-account API, pointing at a user or a channel needs a second value along with the ID: the access_hash.

Why access_hash exists

If a numeric ID were enough to message any user, someone could count upwards through the numbers and spam everyone. The access_hash is proof that this account has legitimately come across this peer. That gives it two properties:

• It differs per account (session). An access_hash your account received cannot be used from another account, so a list of IDs and hashes obtained from someone else cannot be used to send messages.
• You only get it from what the API returns. It comes with user and channel information included in results such as received messages, the chat list, contacts and username lookups (contacts.resolveUsername).

Keep a peer store

The official documentation recommends storing peer information (ID, access_hash, name and so on) persistently on the device. Update it every time a response includes users or channels, and take values from it when you send. That way you do not waste requests looking peers up again after every restart, and you avoid rate limits; see reading API errors.

min: partially filled information

Some user information comes only partly filled, such as users attached to a message in a large group. It is marked min, and its access_hash cannot be used as is in requests.

• If you already have full information stored, do not overwrite it with the min version.
• If you must refer to that peer, you can point at it as "the user seen in this message", using inputPeerUserFromMessage or inputPeerChannelFromMessage.

TDLib manages the peer store for you; see building TDLib. How group and channel types differ is in channels, supergroups and basic groups.