What is open to us at Square, how it differs structurally from Toast, where the data boundary lies, and how this maps onto the four layers of LOCAL.
This is the second-largest player in registers for small venues and the most likely neighbor along the city corridor: among small restaurants Square is strong exactly where we intended to start. The APIs are free, debugging is free, and the sandbox lets us build and test without touching a live restaurant.
| Metric | Value | Source |
|---|---|---|
| Sellers on the platform | more than 4.5M across all industries | public Square materials, 2026 |
| Breakdown by restaurant locations | not disclosed | Block does not publish its number of locations, unlike Toast |
| API price | 0, with no monthly fee and no per-call fee | Square Developer, pricing |
| What the client pays | 2.6% + 10-15 cents per transaction, plus a software subscription | Square pricing |
| Square for Restaurants | $0-60 per location per month | Free / Plus / Premium pricing tiers |
| Official MCP server | yes, in beta status, hosted by Square itself | developer.squareup.com/docs/mcp |
Block does not disclose its number of restaurant locations, unlike Toast. So the statement that there is more Square along our corridor is a hypothesis to be tested by counting registers at specific addresses, not an argument for a decision.
Unlike Toast, there is no door here that only the platform can open. For our own work a personal token is enough, for working with clients OAuth is enough: each seller authorizes our app themselves, and we arrive at their door already as a verified app, with a set of requested permissions.
| Access method | Who issues it | Read | Write | Price | Our status |
|---|---|---|---|---|---|
| Personal access token | we issue it ourselves, from the developer console, for our own account | yes | yes | free | for our own sandbox and our own tests |
| OAuth, flow with a secret | each seller authorizes our app | yes | yes | free | our main path: one app serves many sellers |
| OAuth, PKCE flow | the same, for public clients without a secret | yes | yes | free | needed if we build a mobile app |
| Listing in App Marketplace | Square, after approval as an app partner | yes | yes | free, with a share of partner revenue | not required: we can start without a listing |
With Toast, access is rented from the client: the credentials sit in their account and they can take them away at any moment. With Square we hold the seller's authorization, we refresh the token, and only compliance with the rules depends on us. This is a fundamentally more stable position for a vendor.
Catalog, orders, inventory, locations, service appointments, staff, customers, payments: almost everything is available both for reading and for writing, under approved permissions. Permissions are requested by scope, so we can take read only and not risk the client's data.
| API | What is inside | Read and write | What it gives LOCAL |
|---|---|---|---|
| Catalog | Items, variations, modifiers, categories, taxes, discounts, images | read and write, the ITEMS_READ permission for reading | Core layer: what a dish contains and what can be removed |
| Orders | Orders, checks, line items, payments, sales history | read and write | What was actually ordered. Indirectly relevant to rules |
| Inventory | Item stock counts, SOLD and WASTE states | read and write | "Is it available today" without a phone call |
| Locations | Seller locations, addresses, settings | read and write | Stable attributes and group coverage |
| Bookings | Service appointments: create, change, cancel, search free slots | read and write | Services and scheduled appointments. This is not about restaurant tables, see section 5 |
| Labor | Shifts, timecards, breaks, wages, tips | read and write | Supporting |
| Customers, Loyalty, Gift Cards | Customers, groups, loyalty programs | read and write | Supporting for our layer |
| Payments, Invoices, Refunds | Payments, invoices, refunds, disputes | read and write | Not our topic |
| Webhooks | Events for catalog, orders, inventory, customers, subscriptions | incoming events | Freshness: changes arrive on their own |
Events for catalog, orders, inventory, customers and subscriptions arrive on their own. For LOCAL what matters is the catalog (an item or a price changed) and inventory. One practical detail from the documentation: a catalog event carries only a timestamp, not what exactly changed, so it needs a separate request for changes within a window. This is one engineer-day of work, but it has to be included in the estimate rather than discovered in week two.
Square has released an official MCP server in beta status: remote, hosted on Square's side, sign-in via OAuth, the seller chooses the permissions themselves. Through three generic tools an agent reaches the whole API: payments, orders, catalog and inventory, customers and loyalty, invoices and subscriptions, service appointments, staff, gift cards. There is also a local launch with one command, with a flag that disables writes, and with a sandbox flag.
The layer that another report proposed building as a product, Square already gives away itself and for free: with hosting, with a sandbox and with permissions. Plus on July 1, 2026 Square connected restaurants to ChatGPT and Claude itself, with no commission and no setup on the venue's side. So selling a "gateway to Square" is impossible, neither as an access intermediary nor as a unique integration. The product can only live higher up: in rules, confirmations and the language of the answer.
| Property | Square | Toast | What this means for the choice |
|---|---|---|---|
| Cost of access | free, the client pays for transactions | ~$25 per location per month, an estimate | Square has no expense line that needs explaining |
| Sandbox | yes, free, with no call limits | no, production only | With Square we can debug without touching a live restaurant |
| Access scheme for a vendor | OAuth: the seller authorizes our app | the client's credentials at their location, the vendor does not authorize | OAuth gives us a client list and removes the question of reselling access |
| Write | available immediately, under approved permissions | only through partner certification | With Square an action can be taken without a year of negotiations |
| Official MCP server | yes, beta, hosted by Square | no | Square itself closes the gateway layer we intended to sell |
| Restaurant tables and reservations | no native product, reservations come from third-party apps | the product exists, there is no reservation read access via API | Neither one lets us sell this as an answer |
| Handing data to assistants | Square itself connected restaurants to ChatGPT and Claude on 01.07.2026 | there are no native MCP endpoints | Square closes our reading layer with its own hands |
| Constraint | Value | What this means in practice |
|---|---|---|
| Request limits | not published, the answer on the official forum: we do not disclose | We build on the X-RateLimit-* headers and exponential backoff. Community estimates differ tenfold, from 10 to 100 requests per second per token |
| Token lifetime | 30 days, then refresh via a refresh token | The refresh logic must be written from day one, otherwise the integration dies silently |
| Authorization code | 5 minutes, single use | Client onboarding must be fast, with a retry on failure |
| Refresh tokens | in the flow with a secret they do not expire, in PKCE they are single use and valid for 90 days | The choice of access scheme determines what happens if a token is lost |
| Sandbox | free, unlimited calls, test accounts | Debugging costs nothing and does not touch live data |
| Production requirements | some calls require the client to have a Square software subscription | The same dependency as with Toast: without the client's subscription part of the data is unavailable |
| Hosted MCP | production only, plus a list of allowed clients | For our own sandbox, run a local server with the SANDBOX=true flag |
| What is missing | Fact | Consequence for LOCAL |
|---|---|---|
| Restaurant tables and reservations as a product | Square has floor management and a waitlist in the POS, but there is no separate reservation system for restaurants: reservations and the waitlist are covered by third-party apps from the marketplace, connecting to Square orders and customers | As with Toast, the answer "we can seat eight" cannot be taken from the API. The difference is that Square does not even have a native product to demand access from |
| The Bookings API is not it | The Bookings API covers service appointments: service, staff member, time, free slots | Good for salons and services, not for restaurant tables. Not to be confused |
| Admission rules | Allergens, diets, private room, deposit, minimum check, time limits | Operational policy, not data. It is assembled by hand with the venue, once, and this is what people pay for |
| A public estimate of the limits | Square states directly on the forum that the limits are not documented | You cannot plan load blindly, you need your own measured curve |
| Restaurant density by location | Block does not disclose its number of locations, only 4.5M sellers across all industries | How many restaurants along our corridor are on Square can only be found by counting, not from reporting |
| LOCAL layer | Examples | What Square gives | Who covers it | Lifetime |
|---|---|---|---|---|
| 1. Existence | The venue exists, address, category | Locations, addresses, settings | Square and public sources | years |
| 2. Stable attributes | Hours, zones, payment, online ordering hours | Location settings, catalog, schedules | Square covers it almost completely | months |
| 3. Operational facts | Today's menu, ingredients, stop list, orders | Catalog with modifiers, inventory, orders, webhooks | covers it, and with fresh data | days and hours |
| 4. Perishable | Table for eight, gluten free, private room, deposit | almost nothing | only people: the owner confirms, we keep a record with a date | hours and days |
The three lower layers are covered by eleven lines of code and one webhook. The fourth is not covered by anything. The difference between Square and Toast in the fourth layer is small: neither gives it away, because it is not data but a person's decision made today. That is exactly why the choice of platform does not decide the fate of the product, it only decides the cost of entry.
| Line item | Value | Comment |
|---|---|---|
| Access for us | $0 | Square has no API fee. A saving compared to Toast, but there is also no justification left for a price "for access" |
| Cost at the client | a Square for Restaurants subscription of $0-60 plus a percentage of transactions | Our line item must live on top of that one, not duplicate it |
| Freshness of layers 1-3 | almost zero marginal cost, plus webhooks | The same as with Toast, but with free sandbox debugging |
| Freshness of layer 4 | person-hours | This is where our cost sits, and it does not fall with scale as fast |
| What we charge a group | $2 500-5 000 setup plus $79-99 per location per month | Otherwise the budget conversation ends at the first meeting |
Practically: the second scenario as the product, the first as technical preparation and a way to talk to a venue in its own language, the third only after the second has brought in money.
| Criterion | Winner | Why |
|---|---|---|
| Cost of entry | Square | Zero against an estimated ~$25 per location per month |
| Debugging | Square | A free sandbox against production-only at Toast |
| Stability of access | Square | OAuth on our side, not credentials in the client's account |
| Right to act | Square | Write is available immediately under permissions, at Toast only through certification |
| The reading layer as a product | neither | Square gives away its own MCP server itself, Toast has open wrappers available: there is nothing to sell for either |
| Tables and reservations | neither | Toast has the product but no read access; Square does not even have the product |
| Known market share | Toast | 180 000 locations against an undisclosed number at Block |
| Who pays for the second half of the conversation | both | Both have ready paying categories that we can slot into |
Everything is taken from Square documentation and open sources, dates are given where they are available. Three things are explicitly marked as estimates or as missing data: request limits (Square does not publish them, community estimates differ tenfold), the number of restaurant locations and market share (Block does not disclose them), and the completeness of the picture of tables and reservations in Square (no native product could be found, the conclusion is drawn from third-party apps and Square help). If the opposite is confirmed, sections five and six must be rewritten.
ARLI membership: the notes from the workshop
One site of yours, measured, with the price for the work in the same document
ARLI, Inc., a Delaware corporation. Questions: hq@arliwork.com.