Put more emphasis on common mistakes when getting entities by IDs

readthedocs/extra/advanced-usage/accessing-the-full-api.rst

@@ -112,6 +112,15 @@ as you wish. Remember to use the right types! To sum up:
         ))
 
 
+This can further be simplified to:
+
+    .. code-block:: python
+
+        result = client(SendMessageRequest('username', 'Hello there!'))
+        # Or even
+        result = client(SendMessageRequest(PeerChannel(id), 'Hello there!'))
+
+
 .. note::
 
     Note that some requests have a "hash" parameter. This is **not**

readthedocs/extra/basic/entities.rst

@@ -37,12 +37,24 @@ you're able to just do this:
         # Using Peer/InputPeer (note that the API may return these)
         # users, chats and channels may all have the same ID, so it's
         # necessary to wrap (at least) chat and channels inside Peer.
+        #
+        # NOTICE how the IDs *must* be wrapped inside a Peer() so the
+        # library knows their type.
         from telethon.tl.types import PeerUser, PeerChat, PeerChannel
         my_user    = client.get_entity(PeerUser(some_id))
         my_chat    = client.get_entity(PeerChat(some_id))
         my_channel = client.get_entity(PeerChannel(some_id))
 
 
+.. warning::
+
+    As it has been mentioned already, getting the entity of a channel
+    through e.g. ``client.get_entity(channel id)`` will **not** work.
+    You would use ``client.get_entity(types.PeerChannel(channel id))``.
+    Remember that supergroups are channels and normal groups are chats.
+    This is a common mistake!
+
+
 All methods in the :ref:`telegram-client` call ``.get_input_entity()`` prior
 to sending the requst to save you from the hassle of doing so manually.
 That way, convenience calls such as ``client.send_message('lonami', 'hi!')``