Regarding the md5/sha1 stuff: The documentation as it stands is both wrong and misleading. MD5 and SHA1 are _hash_ functions (not _encryption_ functions), so while trying to suggest that people could encrypt information to put after the + sign is a good idea, you will utterly confuse newbies by giving examples of hash functions. Of course you could use a unique hash value after the +, but then you need a reverse hash lookup table in your app to correlate the hash and the internal app state/data you need (but that is a whole other beast and not nearly as simple as "just encrypt it in the to address, decrypt on receipt, et voilà!").
In the end it is confusing for beginners and outright wrong for people that know the difference.
Now for the constructive part of the criticism: Please change or improve that portion of the docs, since docs are arguably the second most valuable asset to an API-provider (right behind the service itself).
Regarding the md5/sha1 stuff: The documentation as it stands is both wrong and misleading. MD5 and SHA1 are _hash_ functions (not _encryption_ functions), so while trying to suggest that people could encrypt information to put after the + sign is a good idea, you will utterly confuse newbies by giving examples of hash functions. Of course you could use a unique hash value after the +, but then you need a reverse hash lookup table in your app to correlate the hash and the internal app state/data you need (but that is a whole other beast and not nearly as simple as "just encrypt it in the to address, decrypt on receipt, et voilà!").
In the end it is confusing for beginners and outright wrong for people that know the difference.
Now for the constructive part of the criticism: Please change or improve that portion of the docs, since docs are arguably the second most valuable asset to an API-provider (right behind the service itself).