Reporting API - Service Provider needed

TL;DR

There is an attribution bug with Appointments:

  • :white_check_mark: When a customer pre-books online (no human booker) → API correctly attributes to the service provider

  • :cross_mark: When a cashier books the appointment → API attributes to the booker, not the service provider

We need a way to run a report based on the Service Provider the service was rendered with. So something like: ServiceDoneBy , ServiceProvider, ServiceWith

Long Version:

We run a wellness business that uses Square Appointments to manage service-based bookings across about 16 service providers. We rely on Square data to calculate weekly commissions, and I’ve run into an attribution issue that I’d love guidance on.

When I query the Reporting API’s SalesByServiceDate view (or the underlying Orders cube) using team_member_attributed_to_id, the field doesn’t reflect the team member who actually performed the service. According to the documentation, attribution priority is: ownership transfers → ticket assignment → appointment staff → payment collection. In practice, when our front-desk team member books or claims ownership of an appointment, that overrides the appointment staff assignment — even though the appointment was performed by a completely different provider.

Concrete example from the week of May 11–17, 2026:

• Provider N.C. performed 13 appointments based on my Square Appointments screenshots, totaling $1,567.50.

• The Reporting API only attributes 8 orders / $600 in net sales to her.

• The missing 5 orders (~$967.50) are attributed to J.T., who is the booker/front-desk person — not the service provider. Several of these orders explicitly show ‘Booked by J.T.’ in the appointment detail screen.

This affects my ability to calculate accurate provider commissions directly from the Reporting API, which would otherwise be a perfect fit for our weekly reporting workflow.

My questions:

1.. Is there a different dimension or measure in the Reporting API that exposes the underlying appointment staff per order line (Service Provider) — even if team_member_attributed_to_id stays as-is for other purposes?

2. Is there a setting in Square Appointments (or anywhere in the dashboard) that controls how attribution is prioritized? Specifically, is there a way to prioritize appointment staff over ticket assignment / ownership transfer for service-based businesses?

3. If no such setting exists today, is this on the roadmap? Many service businesses (salons, spas, wellness studios, etc.) need ‘who performed the service’ attribution for commission and payroll, separate from ‘who booked / managed the ticket.’

If helpful, I can share specific order IDs from the week of May 11–17 that illustrate the discrepancy. Happy to provide any additional detail.

Thanks for your time — really appreciate the work on the Reporting API; SalesByServiceDate is exactly the right shape for our use case, this attribution piece is the one thing standing in the way.

Hey @TCSlaguna, apologies for the delay here! Just to make sure I’m looking at the same thing as you, can you confirm how to reproduce these two states?

:white_check_mark: When a customer pre-books online (no human booker) → API correctly attributes to the service provider

Is this through an online booking advanced widget (i.e. the booking page with the URL https://book.squareup.com/appointments/…)?

:cross_mark: When a cashier books the appointment → API attributes to the booker, not the service provider

And this is through a booking made on the Square App in Bookings Mode?

Happy to take a look into this and address your questions!

Hi @josh-square! Thanks so much for the response!

Before we discuss team_member_attributed_to_id further, I want to ask the broader question first: is it possible to be provided with a ServiceProvider or BookingWith field/cube/dimension that exposes the team member assigned to the appointment itself — independent of who booked, transferred, or collected? That would solve my problem cleanly and decouple service-performer reporting from the existing attribution-priority logic, which I think genuinely has its place for other use cases.

If that’s not on the table, then yes — happy to confirm the reproduction states for team_member_attributed_to_id.

To your questions:

“When a customer pre-books online (no human booker) → API correctly attributes to the service provider”

Yes. This is through both:

• Online booking advanced widgets per service provider (e.g. https://book.squareup.com/appointments/... style URLs embedded on individual provider pages on our site)
• The general appointments page on our site: https://www.chakrashack.com/s/appointments

In both cases, the customer self-selects (or is system-assigned) a service provider, and team_member_attributed_to_id in SalesByServiceDate correctly resolves to that provider.

“When a cashier books the appointment → API attributes to the booker, not the service provider”

Yes. This is through the Square Appointments app, used by our front-desk team member. The booker selects the service provider in the booking flow (e.g. “Booking with Natalya” for Saturday 4:30 PM), and the appointment is then performed by that provider — but team_member_attributed_to_id resolves to the booker (the front-desk team member) instead of the selected service provider.

For reference, here are two specific cases from May 11–17, 2026:

Provider Natalya: 13 actual appointments per Appointments app screenshots, $1,567.50 total. Reporting API attributes only 8 / $600 to her. The other 5 / $967.50 are attributed to our front-desk team member (Jill ), who booked them via Bookings Mode.

Provider Anastasia: 4 actual appointments, $250 subtotal. Reporting API attributes only 1 / $75 to her. The other 3 / $175 go to the same front-desk booker.

In both cases, the one correctly-attributed order is the pre-paid online booking (no human booker in the chain).

The fundamental issue: for service-based businesses doing commission reporting, what matters is who performed the service, not who booked the ticket. The current priority order (ownership transfers → ticket assignment → appointment staff → payment collection) means whenever a cashier books on behalf of a provider, attribution flips to the cashier — and there’s no way to recover the actual service provider from the Reporting API alone. For my business this means the Reporting API can’t drive provider payroll without a fallback to the Bookings API to recover the truth.

Again, if a ServiceProvider / BookingWith field is feasible, that’s the cleanest solution — it leaves existing attribution behavior intact for use cases that need it, while giving service businesses a clean path to the question they actually need answered. Happy to share order IDs, customer IDs, or anything else useful for the investigation.

Thanks!

@TCSlaguna Thanks for the additional context! I’ll take this feedback to the team as a feature request, although I can’t guarantee that fields like this will be exposed.

In the mean time, I’m working with the team to determine what the expected behavior here is.

Hi @josh-square

Thank you for looking at the expected behavior. I really appreciate it.

And when you send it over to the team, please let them know that:

  1. Appointments gets very little attention

  2. Knowing who has actually done the service is a fundamental aspect of appointment-based businesses.

I appreciate your help.

Hi @josh-square,

I’m just checking in.

Any insight on what the expected behavior is?

Any word on possibly getting a ServiceProvider API?

Thanks!

@josh-square @rsata

Let me sharpen the ask: could Square expose AppointmentSegment.team_member_id as a dimension on SalesByServiceDate?

That field is already required on every AppointmentSegment in the Bookings API and represents “the team member booked in this segment” — exactly the truth needed for commission reporting, decoupled from booker/ticket-assignment/payment-collection logic. Surfacing it on the sales side would let service businesses get “who performed the service” in a single query, without joining Bookings to Reporting client-side.

Hey @TCSlaguna! No word yet on the new dimension request, but I appreciate the added context here and targeted ask. I’ll follow up with this as well.

@TCSlaguna Do you also mind sharing your /v1/load query that you’re currently using when you see these discrepancies?