Dining Option via API and Webhook

Feature Requests
1

When looking up Square POS Transactions we’d like the Dining Option data to be returned so that we can tell what orders were marked as Pickup / To Go / For Here / etc…

3 Likes
2

Yes pls!!
We are missing that too!

3

:wave: We’re constantly working to improve our features based on feedback like this, so I’ll be sure to share your request to the API product team. :slightly_smiling_face:

1 Like
4

@Bryan-Square

While we wait for news on this feature finding it’s way back in API v 2;

Are we allowed to webscrape the web admin module for this info?

5

:wave: It’s not recommended however if that’s the way you choose to get the information since it’s not currently available with the API and if it fits you business you can see if it works. But please note that it’s not supported nor documented so something could change and breaks the webscrape. :slightly_smiling_face:

6

I’m a PM on the Orders API team. Can you please tell me how you want to use Dining Options if available on orders created via POS?

7

Hi Aszerlip

thank you for getting back to us on this.

We use Order and Payments API data to build Sales reports/KPI across Stores.

Knowing how our numbers are performing is paramount, hereunder also how the Eat in/Take Out sales are distributed over a given period wether is time of day, day of week or month-over-month.

Since the Pandemic it has become even more important since we are “battling” new habits from our customers that has gotten used to the take out option.

Making new initiatives based on data beats making them on gut feeling::slight_smile:

thx!

-Philip

8

Hi Philip,

Thanks for that cotext. I’m happy to say that we are actively working to add Dining Options to Orders and will let you know when they are ready to use.

Thanks,
Aaron

9

That is amazing news! thank you!
if you in any way also can find a way to make the historical data accessible, that would be fantastic!

10

Hi,

Before reading… I have no experience with Square POS. I am an individual POS developer, and also a restaurant owner. This topic is interesting. Below is how I did on my POS.

POS don’t need to know ‘to go, pickup, for here.’ However, POS must be able to create order based on [TABLE NUMBER] created by POS. My POS let the end users (restaurant manager) to create sections and tables. If the table number is found, => this is dine-in order (for here order), if table number is not found, this is carry-out order with different table number (either 1. walk-in to-go customer’s name, 2. call-in customer’s name or phone number, or 3. DoorDash/Grubhub/UberEat’s order ==> POS must have ability to print these orders without using extra physical POS printer in kitchen from DoorDash/Grubhub/UberEats… Nobody wants to install extra printer in kitchen taking extra space with extra cost.)

POS can hold many sections. Each section can hold many tables. Each table can hold many seats. Seat-wise ordering system will reduce many problems caused by ‘servers’… In real world. => (Managers want to make sure beverage is added to the seat before adding menu item. If order is created for each seat, it will be super easy for POS to split or combine checks using seat number by ‘One check or separate?’ question.)

Now, when order paper is printed to the kitchen printer, table number will be table number created by manager, for example, (1, 2, 3, 4, 5, 6, 7… or S1, S2, S2… S=[Initial of section name as ‘Small room’], B1, B2, B3… B=[Initial of section name as ‘Beautiful room’]), OR ‘Walk-In carry-out customer’s name entered by employee,’ OR ‘Caller-ID name or phone-number’ caught by modem (POS must have modem to catch caller-ID.).

Now the main point.

  1. Kitchen workers will see table number as ‘1’, ‘2’, ‘3’… ‘S1’, ‘S2’, ‘S3’… or ‘B1’, ‘B2’, ‘B3’… They are dine-in orders. Kitchen workers know what table numbers are created in this business.
  2. Kitchen workers will see table number as ‘Jhon-Doe’, ‘123-123-1234’ => this is either walk-in carry-out OR call-in order. 'Walk-in carry-out must be paid before sending order to kitchen. Walk-in carry-out order will print line as ‘PREPAID’.
  3. Kitchen workers will see ‘DoorDash/Grubhub/UberEats’ on the first line of kitchen order paper instead of [table number]. Kitchen printer must be able to print DoorDash/Grubhub/UberEat orders with title of [DoorDash/Grubhub/UberEat], so kitchen workers can grab to-go box to start order. Kitchen printer will print 2 papers, 1 for kitchen workers, 1 for to be used customer with ‘PREPAID’ line.
  4. Kitchen workers will see customer name for ‘Online Order’ (POS can accept online order with card payment.) with printed line of ‘PREPAID’, which means ‘need grab to-go box to start order.’ Kitchen printer will print 2 copies, one for kitchen and 1 for customer receipt.

I am just hoping this message can help Square because I want to use Square as my future payment carrier. That is it.

Thanks,

11

Hi Philip,

Are you asking if we can backfill dining options on historical orders? This will be done for orders which originated at the POS, but not for orders created via API since they were never assigned a dining option when they were created. I hope that helps.

Thanks,
Aaron

12

Hi. aaron

Yes that was exactly my question, and I’m very content with the answer :slight_smile:

Thanks again for the encouraging news!

13

Hey ETA on when this could actually be released. Been reading and hearing for years that it is being worked on

3 Likes
14

:wave: Currently public roadmaps on features or releases isn’t currently available. :slightly_smiling_face:

15

Hey Bryan, any update on being to acess dining options to orders?

Also, as we are working on an app for Square, we have scenarios where existing customers may be using the Square for Restaurants. Is there any word at all when the Restaurant API will be opened up for us to access? Or do we need to push forward with making our own supplemental middleware? (eg. table numbers, dining options, and so forth).

1 Like
16

:wave: Currently no new update on dining options that we can share at this time.

While a Restaurants API is a popular feature request I’d recommend at this time you move forward with a supplemental middleware. :slightly_smiling_face:

1 Like
17

What do you mean by “move forward with a supplemental middleware”, how do we implement the middleware without the access to dining options of Square POS order.

18

:wave: That was from a previous question on this thread. :slightly_smiling_face:

1 Like
19

Thanks Bryan.

In a restaurant scenario, what issues can you see our app facing if we only have access to the POS API? Will there be certain processes/elements on the restaurant side that we just can’t trigger?

I understand we’ll need to cater for dine in type on our menus (table service, pickup at counter). We’ll need to cater for patrons entering/selecting their table number etc.

We can provide the information via the “note” field (or other fields that make sense) on the orderfulfillmentpickupdetails object which is surfaced on the POS.

But is there anything that could cause us problems if a business using Square for Restaurants, wants to use our app?

20

Any updates or work around this issue, Thanks!