PepperHQ Developer

The PepperHQ Developer Hub

Hand crafted, customised and bespoke mobile experiences to suit your brand and needs.



The Pre-Order scenario is aimed at Users who wish to skip the queue by placing an
Order via the Pepper Powered App that is sent directly to the Merchant for preparation
(e.g. to a thermal printer or KDS in the kitchen - as determined by the PoS


The Pre-Order scenario is aimed at Users who are on their way to the Merchant’s
Location and are ready to collect their Order as soon as it becomes available.
Consequently, it is not currently possible to schedule an Order for a specific time in the
future. Pre-Ordering for a specific time in the future is the role of an online web
ordering system. Pepper are able to integrate with 3rd party web ordering systems at
a level that is appropriate to the Merchant’s needs.

The User builds an in-app basket of Products that they have configured to meet
their specific needs and tastes and then submits it to the Pepper Platform for processing. The Pepper Platform in turn submits it to the PoS' API for preparation.

Any rewards (see description of rewards in the Rewards documentation) that the User is able to redeem are pre-applied to their basket. The User can toggle these rewards on and off as desired.

The menus from which the User can build their basket are specific to each Location;
allowing for differences in the Merchant’s offering from store to store.

The levels of control that the Merchant can assert over how Users can choose their
Modifiers and Options ensures that Catalogues that contain a broad range of
Products can be supported. The Modifier to which Options belong are configured to
specify how they can be selected. For example, it should not be possible to specify no
milk option or multiple milk options for a Cappuccino; but it should be possible to
specify both decaf and chocolate extras for any coffee.

Depending on the capabilities of the Merchant’s PoS, menus are constructed and
retrieved dynamically from the PoS and are not managed in the Pepper Platform
directly. This is designed to avoid swivel-chair administration and to ensure that the
Catalogue remains an accurate representation of the Merchant’s products over time.

The iOS and Android native SDKs are tightly integrated with the Order API on the
Pepper Platform and use a robust polling technique to ensure that Orders can be
successfully submitted for processing even when the mobile device has a relatively
poor connection to the Internet.


Please see the relevant section in the Introduction for a description of how a 3rd Party PoS Connector should be constructed before reviewing the specifics of each of the methods described below.

Get Menu for Location

Retrieves the Menu for the tenant for displaying in the Pepper App. The Menu specific to a Location can be retrieved if the locationId is specified in the request.

getMenuForLocation(locationId, options, callback)

The locationId is the PoS domain's unique identifier for the venue, not the Pepper internal unique id.

If the locationId is omitted, the default menu for the Merchant will be returned.

See for the request and response schema:

The schema that defines the Menu itself can be found at Menu JSON Schema

Create a new Order

Creates an Order for fulfilment at the specified Location.

Payment for the Order is not made if this method is used for Order creation. createPaymentForOrder or createOrderAndPay should be used in cases where payment is required.

createOrder(data, options, callback)

See for the request and response schema:

Create Payment for an Order

Creates a full or partial payment for an Order.

If the amount property is omitted, the full value of the Order will be paid.

createPaymentForOrder(orderId, data, options, callback)

See for the request and response schema:

Create Order and Pay

This is an atomic request that encapsulates the createOrder and createPayment methods. It assumes that the Order will be paid in full.

createOrderAndPay(data, options, callback)

See for the request and response schema:

Validate Order

Pre-submission validation of an Order to ensure it is processable. Beyond schema validation, this also validates that the Order itself is processable (e.g. stock levels). Based on the result, the calling system can make an informed decision about whether to submit the Order for processing.

Validate Order has the added aim of returning helpful information about the impact and characteristics of the Order, including; loyalty impact, basket price, inventory availability and lead-time.

validateOrder(data, options, callback)

See for the request and response schema:

Get an existing Order

Gets an existing Order.

getOrder(data, options, callback)

In this case, data is required and contains the context of the Orders to return. This can be as simple as the identifier for the Order to retrieve or properties to filter on (e.g. table number).

See for the request and response schema:

Get PoS Health

Gets the current status of the PoS service (optionally at the specified Location).

getHealth(identifier, callback)

In this case, identifier is optional and contains the id of the Location for which the PoS health should be tested.

See for the request and response schema:

Updated about 21 hours ago


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.