Skip to main content

Things to Know

Begin in this section to learn about the API environment.

Back Office Domain

Back Office serves multi-unit restaurant brands and franchisees, often in the Quick Service Restaurant (QSR) and Fast Casual Restaurant markets. The mission of Back Office is to empower restaurant operators with detailed, in-depth information to increase their profits; and to improve their operating efficiency.

To achieve this mission, Back Office provides restaurants with a range of tools to manage food and labor costs. Its customers and users range from in-store operators such as cashiers and managers to above-store Directors of IT and Operations.

API Environment

  • The Back Office API environment consists of two stacks: QA/UAT and Production. See Connecting to Back Office for details.

  • Each client exists in its own database, which is complete and separate from any other client's database.

  • All data is read-only, utilizing API "Get" calls.

  • The data generally follows this organization structure:

    • Business Entities

    • Stores within the Business Entities

    • Store level information by business date

Data Classes

Back Office collects and analyzes many data points. These are generally broken into three broad groups:

  • Food (inventory, orders, electronic invoices, transfers, waste/promo)

  • Labor (employees, time clock entries, payroll hours, schedules)

  • Cash (daily cash sheet, tills, miscellaneous financial data, e.g. number of voids)

Data Access

The following is required to access data through the API:

ClientID

Client Domain

  • Uniquely identifies the client to the internal systems.

  • Provided by us.

Credentials

  • Each API user requires a unique username and password (with the correct permissions) to access data. Each username is provided by the client, not us.

  • Each API user requires specific access permissions for the requested data types and the stores where the data resides. Access permissions are provided by the client, not us.

API user

  • Uniquely identifies the API user.

  • A combination of the Client Domain (provided by us) and the username (provided by the client), separated by a period ".".

    • The format is: ClientDomain.UserName

      e.g. if the Client Domain is "SmithCo" and the username is "JDoe", the API user is: smithco.jdoe

Swagger and Postman Overview

Connecting to Back Office

QA/UAT Stack URLs

Production Stack URLs

Back Office API Glossary

Back Office API Glossary

This section identifies terminology used and considerations for the Back Office API environment.

API Consumer

Indicates anyone who uses our APIs. Our clients, third-party vendors, and brand representatives fall into this category.

Business Date

Defines the date by operating hours. Unlike a calendar date that begins at midnight and ends 24 hours later, the business date begins on the calendar date of when the site opens and encompassess all activity until the site closes, which in many instances, is after midnight the following calendar day.

Business Entity

The operation company.

Cash Sheet

Provides a comparison summary of overall sales to monies collected. Differing amounts determine if the site is over or short for the business day.

ClientID

Also known as a globally unique identifier (GUID). The ClientID identifies the API Consumer and is required in order to connect to the our API. The ClientID provides the ability to track data consumption, and to limit or remove connection access.

The ClientID does not imply that the API Consumer is our direct client, nor does it provide access to customer data.

Departments

Classifies a job type, such as Crew or Management. Sometimes referred to as a Job Code.

Inventory Location

Identifies where inventory items, such as meats, produce, and paper products, are stored. Inventory Locations include areas such as a walk-in cooler or stockroom.

Because not all sites have the same layout, physical inventory locations vary.

Point of Purchase

An area within the site where sales are made, e.g. Front Counter, Drive Thru, Mobile.

RTIconnect User

Each Back Office API Client requires a User ID account in order to access the data within a client database.

We do not create or configure these users. It is the responsibility of the Back Office customer admin to provide the User ID and password to the respective API Consumer.

Search Data

The result set of a query. Search parameters that return search data typically include a date range.

Example: The API Orders data set search is /api/v1/order/search. This API returns a list of the Orders within the specified date range.

SiteNumber

A Brand/Franchisor assigned number for the Store/Restaurant. The SiteNumber is optional.

The SiteNumber is unique only for a single client, not across different clients.

Store

The term used to reference a specific restaurant or site.

StoreID

A unique internal number assigned to a Store for the client.

A StoreId is unique only for a single client, not across different clients.

StoreNumber

A client generated number for the Store/Restaurant. The StoreNumber may not align with the Brand/Franchisor SiteNumber.

The StoreNumber is unique only for a single client, not across different clients.

Swagger

An industry standard tool used to document and test APIs.

Familiarity with Swagger is a requirement for using our APIs. Swagger training is beyond the scope of our services.

See also:

The operation company.

business datecash sheet

Also known as a globally unique identifier (GUID). The ClientID identifies the API Consumer and is required in order to connect to the our API. The ClientID provides the ability to track data consumption, and to limit or remove connection access.

The ClientID does not imply that the API Consumer is our direct client, nor does it provide access to customer data.

Indicates anyone who uses our APIs. Our clients, third-party vendors, and brand representatives fall into this category.