How an AI Kiosk Integrates With Square POS (And What Square's API Actually Allows)

Square is the most common POS at the indie retail stores I work with. If you are evaluating an AI kiosk and you run Square, the first practical question is: what does the integration actually look like? The honest answer involves Square's OAuth flow, a small set of API endpoints that matter, and a number of capabilities that are technically possible but require the integration to be built well. This post is the framework — not a sales pitch — for how to evaluate any kiosk-style assistant that claims Square integration.

I will describe Square's API capabilities generically and what is possible "when integrated correctly." I am not going to over-promise on what any specific product does today; what is described here is the shape of a well-built integration with Square's published API.

The OAuth flow

Square uses OAuth 2.0 for third-party integrations. The high-level flow:

1. The operator (the merchant) clicks "connect Square" inside the kiosk vendor's admin panel.
2. They are redirected to Square's authorization page where they log into their Square account and review the requested permissions (called "scopes" in Square's terms).
3. They approve, Square redirects back to the vendor with an authorization code.
4. The vendor exchanges the code for an access token and a refresh token.
5. The access token is stored encrypted on the vendor's side and used for all subsequent API calls. The refresh token rotates the access token periodically (Square access tokens currently expire after 30 days).

The operator can revoke the connection at any time from their Square dashboard. That is the right model — the merchant is in control of the connection, not the vendor.

What you should look for as a buyer: the scope list at the consent screen should be specific and minimal. If the vendor asks for every Square scope ("just in case"), that is a red flag. A read-only catalog integration does not need write access to your transactions.

What Square's API exposes (when integrated correctly)

Five categories of data that matter for an in-store AI assistant. For each, what the API can do and what a correct integration would actually use.

Catalog (products, variations, prices)

Square's Catalog API exposes products, variations (sizes, flavors, colors), prices, modifiers, and categories. This is the foundational data for any in-store AI assistant. Without product data, the kiosk cannot answer "do you carry X" or "where is Y" questions accurately.

A correct integration syncs the catalog read-only. The kiosk reads product names, descriptions, prices, categories, and (if the operator has configured them) custom attributes. It does not write back to the catalog. Catalog writes belong in Square or in the operator's dashboard, not in the kiosk's logic.

Sync frequency matters. A daily sync is too slow if you change prices or run flash promos. A real-time sync is overkill and burns API quota. The right answer is usually webhooks for changes plus a periodic reconciliation sync.

Inventory (stock counts)

Square's Inventory API exposes stock counts per item per location. For multi-store operators this is critical — the kiosk in store A should not recommend a product that is out of stock at store A even if store B has it.

Correct integration: read inventory at the location level, refresh it on a reasonable cadence, and gracefully handle "out of stock" by either suggesting alternatives or telling the customer. A kiosk that cheerfully recommends a sold-out product is worse than no kiosk.

Locations

Multi-store operators have multiple Square locations. The kiosk needs to know which physical location it is installed at, and that has to map to a specific Square location ID. Otherwise the kiosk is reading the wrong inventory and the wrong catalog (catalogs can vary by location).

This is a setup-time problem, not a runtime problem, but it is the most common failure mode in multi-store rollouts. The vendor's onboarding should explicitly map each kiosk to a Square location.

Transactions and orders

Square's Orders and Payments APIs expose sales data. The right kiosk integration is read-only here too — and used sparingly.

What it is good for: identifying best-selling products at the store level (so the kiosk can answer "what's popular here this week"), validating that promotional campaigns are working, and informing recommendation logic with real local sales patterns.

What it should not be used for: identifying individual shoppers from their transaction history without consent, training a model on transaction-level data, or anything that smells like surveillance. More on this in the post on POS data privacy.

Customer data

Square has a Customers API that includes customer profiles, contact info, and (if the merchant uses it) loyalty data. This is the most sensitive scope and the one operators should be most careful about granting.

A well-built kiosk integration usually does not request customer scope at all. The kiosk does not need to know the shopper's identity to answer their wine pairing question. If the kiosk does have access to customer data, the use case has to be clear, narrow, and consent-based — for example, an opt-in loyalty experience triggered by the customer scanning a QR code.

If a vendor is requesting customer scope by default, ask why and do not accept "for personalization" as a sufficient answer.

What the integration does not do (be skeptical of claims)

A few things vendors sometimes promise that Square's API does not actually let them do — or that they should not do even though they technically can.

Process payment. A kiosk-style assistant in the configurations I am describing does not handle payment. The customer pays at the register. Anyone claiming a kiosk-plus-payment integration with Square is describing a different product (Square's own self-checkout terminals or a custom Square Reader integration). Different scope, different conversation.

Verify age automatically. Square does not have an "age check" API and would not be the right place for one anyway. Age verification is a register-side action by a human, not a kiosk action.

Override prices. A kiosk should never write prices back to Square. If the kiosk shows a different price than the register, the register wins. The kiosk's job is to read accurately and reflect what the operator has set in Square.

Pull employee data. Square has employee-level data (time clock, sales by team member) but the kiosk has no business reading it. If a vendor asks for that scope, push back.

What a clean integration looks like in practice

If you are evaluating a kiosk vendor's Square integration, here is the checklist I would run them through.

1. OAuth scopes: Read-only, minimal, and specifically named. No wildcard "all permissions" requests.
2. Catalog sync: Webhook-driven for changes, periodic reconciliation, location-aware.
3. Inventory sync: Per-location, refreshed at least every few minutes during business hours, gracefully degrades when stock is unknown.
4. No customer-data scope by default. If it is requested, the use case is narrow and explicit.
5. No payment scope. Period.
6. Disconnect is clean. When the operator revokes the connection from Square, the kiosk visibly degrades to a no-data state — it does not keep operating on stale data forever.
7. Data deletion on disconnect. Within a documented window (30-90 days is typical), the vendor purges synced Square data.

Ask each of these questions explicitly. A well-built integration has a clear answer for all seven.

Where this fits in the larger evaluation

POS integration is one of the seven categories I lay out in the questions to ask before buying retail AI checklist. It is important but it is not the only thing that matters. A kiosk with great Square integration but bad bilingual support, or great integration but a privacy model you do not trust, is still not a kiosk you should buy.

For Remi specifically, our Square integration follows the read-only, minimal-scope, location-aware pattern described above. We do not request customer scope by default and we do not handle payments. The integration's job is to keep the kiosk's product and inventory data accurate; everything else stays in Square where it belongs.

If you run Square and want to talk through what the integration would look like in your specific store, we can demo it. If you do not run Square — most of this framework applies the same way to Clover, Lightspeed, and Toast, with slightly different API specifics. See the Clover vs. Square comparison if you are still picking a POS.

Frequently asked

Does the kiosk slow down my Square POS?

No. The kiosk reads from Square's API; it does not interact with the register or affect transaction processing. If a vendor's kiosk is in any way in the payment path, that is a different and more invasive integration than what is described here.

What happens if I disconnect Square?

The kiosk should visibly degrade — product lookups stop working, inventory shows "unknown," and the operator gets a notification. Stale data should not persist. Ask each vendor what their disconnect behavior is.

Can the kiosk update my Square catalog?

A well-built integration is read-only. If the vendor wants write access to your Square catalog, ask why. There are valid reasons (syncing a master catalog from the vendor's admin panel), but the default should be read-only and the writes — if any — should be optional and explicit.

How long does the integration take to set up?

OAuth connection itself is two minutes. Initial catalog sync depends on how big your catalog is — a 5,000-SKU store usually finishes in under an hour. Mapping kiosk-to-location for multi-store deployments adds setup time but only once. See pricing for the all-in setup commitment for a Remi pilot.

Does this work for Square for Restaurants?

Square for Restaurants uses the same underlying APIs with some additional restaurant-specific data (modifiers, courses). An in-store AI kiosk in a restaurant context is a different use case from indie retail. Most of this framework applies; some restaurant-specific configuration changes.