Allof those systems(well at least the ones I've personally worked with, e.g. Micros, Agilysys) have their own APIs that are published by the vendor, so you can ask for them; they're part of their folio management and property management modules, to wit. (what I was doing was related to payments, so I didn't use those parts. Ironically, when I asked for some payments APIs, they gave me docs for the kind of stuff you are needing! haha. at the time they didn't have payments API, so we usually had to make that ourself).
That being said, I do want to mention a couple things that may be useful:
* those that have APIs will usually want you to get in some 'developer program', which can be quite expensive, and take a while to to get 'approval' from their relations departments. The cost is all over the map vendor-to-vendor. (They do this really as a throttle on inbound requests, rather than to make money from the developer program.). What worked for us is to have a marquee customer who wants your product, and then they go either to the dealer of the POS system, who will push it up to the vendor, or in some cases if the customer is very large, they can talk to the vendor directly. Then you'll find that you can often get these developer documents, etc, for no (or little) cost, and much faster than going through the developer programs' front door, and also better support (if any does exist) for your project.
* I'm not aware of there being an 'API aggregator' across all the POS systems for this stuff, but maybe things have changed since I was working on it. If there isn't, then this is also a business opportunity to you to monetize your technical infrastructure in a way additional to the market vertical you're already pursuing (parking, valet, etc). This happened to us in payments: we (unexpectedly) got folks making other products who wanted to use our internal APIs for payments, because we had effectively unified the POS space with a common, simple API.
* you might be motivated to pursue the largest POS vendor first, because of market reach. while this is logical, you may also find the the largest POS vendor is the least interested in working with you, whereas smaller ones are much more cooperative, and can get you into market quicker. you'll also find that once you have a couple deployments proving your concept, then the larger vendors will suddenly become more cooperative. So, unless you have specific business opportunities driving your plans on which to integrate first. you might consider focusing on which get you into market first, which may be 'tier 2' vendors. It's sooo much easier making a compelling case for your product once it already exists, than at the beginning explaining it conceptually. Humans are naturally skeptical creatures.