Single-location restaurant on Square for Restaurants, all staff on personal passcodes, with an in-house app built on the Orders/Payments/Labor APIs for tip attribution and reporting.
The gap: Square for Restaurants tracks check ownership — checks are assigned to a team member, can be transferred between servers at the POS, and the per-employee shift reports attribute a transferred check’s sales and tips to its current owner. But none of this is visible in the API. The Orders API exposes only:
created_by_team_member_id— the opener, immutable, wrong the moment a check is transferredteam_member_idon each Payment — who processed the tender
We verified this empirically: printed per-employee shift reports and API data diverge by exactly the transferred checks (the shift report follows ownership; the API can only follow openers or payment-takers). We also diffed the full order payloads of a transferred check against a never-transferred one — byte-identical structure. The ownership data demonstrably exists on Square’s side; it just never reaches the API.
The ask, in order of value:
- A current-owner field on the Order object (e.g.
owner_team_member_id), maintained through transfers - Ownership history (or transfer events via
order.updatedwebhooks), so a check that changed hands mid-shift can be attributed by time span
Why it matters: any integrator doing tip pooling, tip attribution, or per-server sales reporting has to pick a proxy — opener (wrong after transfers) or largest-payment-taker (wrong when a manager helpfully takes a payment on a server’s check). Both proxies systematically misattribute money between employees, which in tip terms means real pay errors. The shift report proves Square already resolves ownership correctly; exposing that same resolution via the API would let integrations match Square’s own numbers.
Happy to provide order IDs demonstrating the divergence if that helps.