API Docs

Init2 & Gatekeeper

GET /init2

The /init2 API call was created to keep backwards compatibility with existing users. You should use this call going forward, because it's more robust, and it includes the ability to include/exclude things depending on what you need. Init2 also can include the new /gatekeeper API for your bootup sequence.

Options are now appended as URL parameters, instead of the /arg1/arg2 structure. e.g.: /init2/arg1=foo&arg2=bar.

Possible URL parameters

• copy=1|0: Whether or not to include copy. Defaults to 1.
• date={date}: Same usage as existing init.
• gatekeeper=1: Defaults to 0. If this is included, lat and long are also required in order for the gatekeeper API to execute (otherwise nothing will happen).

Examples

• Same as /init: /init2
• Same as /init/{date}: /init2?date=2015-10-22
• Same as /init/{date}, but let's add the gatekeeper API in there too: /init2?date=2015-10-22&gatekeeper=1&lat=37.76637243960176&long=-122.41473197937012. Notice that you need gatekeeper=1
• Perhaps you don't need the app copy on every init request. Set copy=0: /init2?date=2015-10-22&copy=0&gatekeeper=1&lat=37.76637243960176&long=-122.41473197937012

GET /gatekeeper/here/{lat}/{long}

Let's talk about this new big thing.

What to look at:

• isInAnyZone: Is the customer even within any service area?

• AvailableServices: What is currently "on", based on what's set in the admin. The only thing to really look at here is the OrderAhead object, which contains everything you need for building the OA menu.

  • OrderAhead:
    • You'll need to pass kitchen and zone back to me when the user sends an OA order.
    • availableMenus is the mothership. That should have everything you need, and it's the same type of format that you've already been using. They're already sorted in the order that they should appear in the dropdown. Also, don't forget to look at the quantities of each item, per menu. So when the user selects "Feb 1 Lunch" versus "Feb 1 Dinner", those are different qty's.
      • Each menu has a Times array that tells you how to build the available times selection for a menu, and which are available. Later on "available" could be false, and that time should be marked as "sold out".

• appState. See possibilites here: Logic: appState Decision Tree

• appOnDemandWidget: Use to build the OD widget!

  • "selected": true|false: Whether or not it defaults to being selected. If false, select the first OA option.

    • IF selected is false, then menuPreview will be populated for you to use with the "view menu" button.
    • ELSE, menuPreview will be NULL, and mealMode will be populated with the proper menu to use from the existing /menu/{date} API call (or from within /menu/{date} nested within the /init2 call).

  • "title" and "text": Obvious, hopefully.

  • "state": "open|sold out|closed". Same states as you get now. You don't really need to do anything with this. If the store is sold out, then I go and get the sold_out text, and I set it here as the text. So you don't have to do anything extra.

  • "menuPreview": null|{menuObj}. If the store is closed or sold out, then this will be populated with the menu object that you use to show the user the menu preview (this is equal to the "view menu" button that you would tap on the existing closed/soldout walls--I am just putting it here for ease).