Yes, the
5La7FKDZAMA5Hr4N8 is just a 'random' identifier, it not unique to the location, but unique to the particular short link. The short url service looks up that key in database to find the full link. ... there is no direct API for the google URL shortener.
Although in theory can just make a HTTP request to the short URL, and it should reply with a HTTP redirect to the 'full' url, so get back the full url
in Location header.
The problem is that still isn't directly decodable. Pretty sure there is a 'place id' in encoded in the url encoded protocol buffer (ie the id for The Louis in that example),
0x30e29f76120e2781:0x93aa21eeb98e2ebb
which in theory could be used with the PLaces Details API, which may even return a plus code directly!
Note entirely sure how to convert the one in the URL to the one the API needs. The one in URL seems to be hex encoded, but the API wants a different format.
(However not totally sure you are allowed to store the location returned from the Places API in a database, even if you are re-encoding the lat/long as a Plus-Code. Read the Terms carefully.)
There IS a simple lat/long in the long URL - just after the @ symbol, which can be turned into a Plus Code easily. But, its the location of the center of the map, NOT of the searched feature.
... The feature typically isn't centered. The feature often starts centered in the 'visible' map on Google Maps, but hte @ location is the actual center, and the map may technically go behind the 'sidebar'.
Of course the user may of dragged/moved the map between searching, and producing the short link! (or even copying a long link direct from browser!)