MERGEPORT API, Controller or both: choosing the operating model

MERGEPORT can participate in a restaurant-technology workflow in more than one way. A product can connect its backend through the REST API, operators can work with the MERGEPORT Controller, or a setup can combine both.

The right choice depends on where decisions should happen: inside your product, in an operational interface, or across both layers.

Use the API when your product owns the workflow

A direct API connection is the natural choice when your application already has the user interface and operating logic its customers need. Your backend exchanges supported data with MERGEPORT while your product remains the place where users work.

This model typically fits POS vendors, ordering platforms and restaurant-technology providers that want to embed the connection into their existing product. Their teams control how orders, status changes, item data and errors appear to users.

The API documentation describes the technical contract. The exact endpoints and data flows required for a rollout depend on the systems being connected.

Use the Controller when operators need a dedicated frontend

The MERGEPORT Controller is the operational interface for restaurant locations. In supported setups, it can centralise tasks such as managing connected ordering channels, reviewing incoming orders and working with configuration relevant to the location.

This model is useful when there is no suitable frontend in the connected product, when a tablet-based operating flow is preferred, or when the location needs a direct place to manage the connection.

The Controller is not a substitute for every POS or ordering-platform function. Its role should be defined around the concrete setup and the integrations involved.

Combine both when technical and operational responsibilities differ

A combined model separates system-to-system exchange from day-to-day operation. The API handles the backend connection while the Controller gives operators a dedicated interface for the tasks assigned to them.

This can be useful when:

• a product needs automated data exchange but restaurant staff still require an operational view;
• configuration belongs in the Controller while business logic remains in the connected product;
• support teams need a shared operational reference without moving the complete product workflow.

Four questions that make the decision easier

Before selecting the model, answer these questions with product, engineering and operations:

1. Where should an incoming order first become visible?
2. Which system is responsible for accepting, rejecting or updating it?
3. Where are channel credentials and location configuration managed?
4. Which team investigates a failed or delayed data flow?

If all answers point to your product, start with the API. If operators need a separate workspace, include the Controller. If ownership is split, define a combined model explicitly.

The best architecture is the one with clear responsibilities. Choosing the interface is only the first step; documenting who acts where prevents gaps during implementation and support.