Your restaurant should retain ownership or the highest available administrative control of its delivery marketplace accounts, even when an aggregator manages orders. Use restaurant-controlled recovery contacts, give the provider only the access it needs, and agree on an exit process before service begins. The exact roles and transfer options depend on each marketplace and location.
An aggregator connection and a marketplace account are different things. Changing the software that sends orders to your kitchen should not mean losing the ability to manage your restaurant's marketplace presence. The way to protect that control is to inventory each account, identify who can recover it, and verify what happens when the connection is removed.
Start with the accounts your restaurant uses
Make one entry for each marketplace and restaurant location. A two-location business using three marketplaces may have different administrators, recovery contacts, and connection settings for each location. Do not assume that access at one store carries over to another.
For each entry, record the marketplace account name, location, restaurant-side owner or highest available administrator, other administrators, and the email and phone used for account recovery. Also note who receives billing notices and who can request changes to the listing. These may not be the same person.
Use an email address controlled by the business rather than a provider's address or an employee's personal inbox. Make sure more than one authorized restaurant leader can reach the recovery channel under your internal security procedures. Record where credentials are held, but do not put passwords or recovery codes in a shared spreadsheet.
Then mark anything you cannot verify. If a former manager set up an account, for example, you may know the listing exists without knowing who can reset access. Assign a restaurant-side person to resolve that gap with the marketplace. Ask what documentation is needed to establish or transfer the business's administrative access.
This distinction matters: a provider can be authorized to operate a connection without being the restaurant's account owner. Ask each marketplace which role is available to the restaurant, which role the provider needs, and whether separate user access is possible. If a shared login is the only option offered, document who holds it and how you will change it when the relationship ends.
Map the provider's access and connections
For every location and channel, identify the route an order takes: marketplace account, aggregator connection, POS or other order destination, and kitchen output. Record the provider responsible for each link. A connection can stop working even while the restaurant still controls the marketplace account, so both account access and order routing belong in the inventory.
Ask the provider to show the setup for your exact marketplace, location, and POS combination. Find out whether it uses an individual user account, a shared credential, an authorization, or another connection method. Who can create it? Who can disconnect it? Can the restaurant see its status, or must the provider make changes?
Also separate actions the connection supports from work someone must do manually. Ask who updates hours, menu items, prices, modifiers, and availability on each channel. Confirm how cancellations, rejected orders, and other exceptions reach staff. Do not assume that because orders appear in one place, every listing change or exception follows the same route.
When comparing restaurant integrations, check availability for the actual setup rather than relying on a general integration list. Fleksa's directory distinguishes live connections from connections available on request. For example, ask about the Uber Eats integration for your location and order destination. Fleksa lists Toast and Square POS connections on request; confirm what is available before making a decision.
If you are deciding whether to connect channels through a POS or an intermediary, the guide to direct POS integration and middleware can help frame that choice. For account control, the important follow-up is the same in either case: who can change or remove each connection without surrendering the marketplace account?
Use an exit inventory to assign the work
The following is a hypothetical inventory for one restaurant location. It illustrates how to assign decisions; it does not describe a particular marketplace's permissions. Keep the working version in a restricted place and update it whenever a person, provider, or recovery contact changes.
| Item | Restaurant owner | Current situation | Next action |
|---|---|---|---|
| Marketplace A account | General manager | Restaurant admin access confirmed; recovery email is a business inbox. | Confirm the recovery phone and review other admins. |
| Marketplace B account | Operations lead | Listing is active; account owner is unknown. | Ask the marketplace how to establish restaurant admin access. |
| Aggregator connection | Operations lead | Provider manages the connection; removal steps are unclear. | Get written disconnect and reconnection steps for each channel. |
| Order destination | Shift manager | Orders route to the current POS setup. | Confirm the replacement route and the staff procedure if orders do not arrive. |
The table separates account ownership from the technical connection. In this example, the first decision is not which replacement aggregator to buy. It is whether the restaurant can establish administrative control of Marketplace B and obtain a workable transfer process. Until those questions are answered, a provider change has an avoidable dependency.
Add your own entries for every channel and location. Include a responsible person and a next decision for unresolved items, such as whether a marketplace can move an existing listing to a new administrator or requires another process. Record the provider's promised response time and the contact for escalation, but treat those as agreed terms to verify, not automatic protections.
Keep a separate change record with dates: who granted access, what role was granted, why it was needed, and when it was removed. Review it after a manager leaves as well as when a vendor changes. A departing employee may still control a recovery inbox or an administrative login even if the aggregator remains the same.
Agree on transfer steps before cancellation
Ask for a written exit sequence before signing or renewing. It should say who starts the request, what notice applies, which party removes each connection, and how the restaurant regains or retains administrative access. Ask whether the marketplace must approve any step and what happens if the incoming provider cannot connect on the planned date.
Set a handoff window when someone from the restaurant can monitor orders and reach both providers. Avoid making access changes during your busiest service. Identify a temporary operating procedure for each channel, including who watches for incoming orders and how staff will enter or communicate them if the normal route is unavailable. Confirm that the procedure is permitted and workable for your setup.
Before disconnecting the outgoing provider, verify that the restaurant can access the marketplace account and its recovery channels. Record the current configuration and contact details without collecting customer information. Agree on when the old connection will be removed and when the replacement will be activated. Do not assume both can operate at once, or that a changeover will be uninterrupted; ask the marketplace and providers how the transition works.
After the handoff, review administrator access and remove the outgoing provider's access where appropriate. Change any shared credentials under your security procedures. Confirm that recovery messages go to the intended business contacts and that staff know whom to call if a channel or order destination stops working.
Verify the route without creating a real order
First ask both providers what simulated or sandbox checks are available. A practice scenario must not charge a real card, send a guest message, or dispatch a courier. Do not submit a normal marketplace order as a practice check unless the marketplace and providers have supplied a safe method that prevents those actions.
In a simulation, use a unique test identifier and a simple order with a modifier. Match the source order to the expected POS and kitchen result. Compare the items, modifier, and total, then check a supported exception such as a rejection if the setup allows it. Record the expected and observed results without private customer data. An unsupported exception is a limitation to document and plan around, not a failed requirement unless you agreed it was required.
A simulation checks only the route and conditions it represents. If you also arrange a live service pilot, treat it separately: agree on its scope, staff coverage, real-order handling, and escalation plan with the relevant parties. Monitor the first service period closely and record actual issues. Neither a simulation nor a pilot guarantees that every later order will arrive correctly.
For your next step, bring your channel list, access inventory, and test cases to a Fleksa demo. Ask which connections are available for each location and how access and disconnection would work before you commit to a change.
Frequently asked questions
Should an aggregator own my marketplace account?
Prefer restaurant ownership or the highest administrative role the marketplace offers, with the provider given the access it needs. Confirm the available roles and recovery process with each marketplace.
What should I do if a former provider controls the recovery email?
Contact the marketplace to establish restaurant access and ask what proof it requires. Assign someone to follow the request through, then update the recovery contact and review authorized users.
Does disconnecting an aggregator transfer my account?
Do not assume it does. Disconnecting a technical link and transferring administrative control are separate steps. Get the sequence from the marketplace and both providers, then verify access and routing after the change.
