Connect to your
favorite tools

No, and you should not assume otherwise from a card appearing in the grid. Availability turns on three separate things, and all three have to line up. First, your Vertex plan: which integrations are included, and whether any sit behind a higher tier or a module, is a commercial question that is settled in your contract rather than on a marketing page. Second, your region: the ordering and delivery platforms in this catalogue operate in different countries under different entities, some are not present in your market at all, and accounting and payroll tools differ by jurisdiction because the tax, filing and banking rules they are built around differ. Third, the partner's own product: an integration is written against a specific API, and access to that API is frequently tied to the plan, tier or account type you hold with that company. Being a customer of theirs does not by itself entitle you to the API the connection needs, and older or self-hosted versions of a product may not expose it. So the useful thing to do is send sales a list of the exact systems you run — the product, the plan or edition you are on with each, and the countries you trade in — and ask which of them can be connected today, which are on a roadmap, and which cannot. Get that in writing rather than reading a logo into a promise. On cost, the page's hero says "no extra charges", which is the page's wording and needs confirming against your quote; either way, whatever you pay the third party for their own product is a separate bill that is between you and them.

Connecting an app means sending your data to another company, and it is worth being plain about that rather than dressing it up as syncing. Once a connection is authorised, the categories of information the marketplace cards describe start flowing outward: sales and transaction records, menu or product data, customer records and purchase history, staff clock-in and tip data, and the reports built on top of them, depending on which app you connect and what you enable. From the moment it leaves Vertex, that data sits in the third party's systems and is governed by their terms of service and their privacy policy, not by ours. Please read those documents before you authorise anything, and read them for each app rather than once. We are not going to make claims on any of these companies' behalf. We do not state where they store your data, what they retain and for how long, whether they use it to train models or improve their own products, who they share it onward with, which security standards they hold, or what uptime they offer — none of that is ours to certify, and any of it can change without us being told. Ask them, or check their trust and privacy pages. There is also a legal dimension worth taking to your own adviser: depending on where you trade, sending customer records to another company may make you responsible for having a lawful basis and, in some cases, a data-processing agreement in place, and for telling your customers what you do with their information. Practically, connect only the apps you have a reason to connect, grant the narrowest access the app offers, review who at your business can authorise connections, and disconnect anything you stop using — noting that disconnecting stops future data flowing but does not by itself delete what the third party already holds, which is a deletion request you make to them.

Connections break sometimes. That is not a caveat we are adding reluctantly; it is the nature of joining two systems that are owned and changed by two different companies. An integration is a running conversation between Vertex and a partner's API, and either side can alter that API, deprecate an endpoint, change a field, tighten a rate limit, or have an outage of its own. Authorisations expire or get revoked — a password change, an expired token, someone removing the user account the connection was set up under, or a plan change on the partner's side will all quietly stop data moving. The page's why-connect cards describe two-way syncing without delays or manual exports; treat that as a description of how the connection is designed to behave when everything is healthy, not as a promise about every minute of every day, and flag it for verification. So plan for the failure case. Decide who at your business owns each connection and would notice if it stopped. Check the connection status and the receiving system after you change anything material — a menu restructure, a new tax rate, a new site, a staff account being closed. Reconcile the important flows periodically against source records rather than assuming the two systems agree, particularly for money: sales totals, payouts and accounting postings are worth spot-checking rather than trusting silently. Keep a manual fallback for anything that would stop service if it went down, especially order feeds during a busy shift. And when something does break, expect the fix to involve both parties — sometimes it is a reauthorisation you can do yourself in a couple of minutes, sometimes it is a change on the partner's side that we can raise but cannot control.

"2-minute setup", "avg setup 2 min" and "no code" are the page's own words, and they are describing one specific step honestly enough: the authorisation handshake. For an app that uses OAuth, you sign in to your account with that company, review the access it is asking for, approve it, and the connection is established. That part is genuinely short and does not require a developer. What that number does not cover is the rest of the job, and the rest of the job is mostly yours. The credentials are yours — you need an active, appropriately privileged account with the other company, and someone with authority to grant access on your business's behalf. Then comes mapping, which is where the real time goes: matching your Vertex menu or product records to the other system's items, deciding which revenue categories post to which accounts, aligning tax codes, matching site and staff records across the two systems, and choosing what syncs in which direction. Clean data on both sides makes this quick; messy data does not, and no amount of automation resolves an ambiguity about which of your two "Large Latte" records is the real one. After that, test with a small volume before you rely on it — put a few real orders through, confirm they arrive where you expect, and check the totals against your own records for a day or two. Ask sales for a realistic setup estimate based on your actual app list, your item count and your number of sites, and treat the two-minute figure as describing the click-through, not the project.

Two separate things, and the first one deserves care. The why-connect card says every app is verified and tested by the Vertex team — that is the page's wording, it should be confirmed with us before you rely on it, and even taken at face value it means something narrower than it sounds. Verification of that kind is about whether an integration behaves correctly against our platform: whether it authenticates, whether the data it moves lands in the right shape, whether it handles errors sensibly. It is not a security audit of the other company, not a certification, and not a warranty of their product, their availability or their handling of your data. So do not read the word certified as our stamp on a third party's business — the questions in the data-sharing answer above still apply to every app in this catalogue, verified or not. The API is the more straightforward half. The developer band on this page describes a documented REST API and webhook system covering sales data, menu management and customer records, with a route to submit an app to the marketplace. That is the path if the tool you need is not listed: build against the API yourself, or have your supplier do it. Two practical notes if you go that way. An API you build on is a dependency you now maintain — versions move, and something has to be responsible for keeping your integration current. And before you scope anything, ask us for the current documentation and for what the marketplace submission and review process involves, including rate limits, sandbox access and what happens to an app once it is listed.