Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Contents

Overview

The RBI Loyalty API is used to allow guests to redeem offers and rewards when ordering in a restaurant. This Reference Guide is meant for software developers who would like to integrate a client application (typically a POS or Kiosk) with RBI Loyalty. Before reading this guide, please have a look at the customer journeys that are supported by the Loyalty API, all documented under Loyalty API - In-Store Customer Journey.

To access the Loyalty API, you will need to ask RBI for access to a Staging environment, and you will receive an API key. Please follow the steps below to make your first call to the Loyalty API.

Environments

Along with the API key, you should have received an environment URL with the following format:

https://{reg}-{env}-{brand}-loyalty-middleware.rbictg.com

Where:

  • Region {reg} variables:

    • euc1 EU Timezone Markets

    • apse1 APAC Timezone Markets

    • euw3 Iberia Timezone Market

  • Environment {env} variables: dev, staging, qa or prod

  • Brand {brand} variables: bk, plk or fhs (other brands are not supported in International markets yet).

All paths indicated in the endpoint documentation are relative to your environment’s base URL.

Headers

All API requests should include the following fields in the header:

  • x-region <string>: 2-character ISO country code, e.g. DE for Germany.

  • x-api-key <string>: environment, vendor and brand-specific API key generated by RBI.

  • x-user-datetime <string>: local date/time string in ISO format.

Endpoints

The Loyalty API uses multiple endpoints, which are documented here: Loyalty API - V1 Current.

Using the API endpoints should follow this pattern:

  • Call the Identify (Loyalty API v1 - Identify) endpoint using either the Loyalty Code or the unique code generated when offers/rewards are pre-selected

  • Call the Transaction Validate (Loyalty API v1 - Validate) endpoint to check that the contents of the basket is valid. The endpoint will return errors in multiple scenarios documented here: Loyalty API - Error List. For an optimal guest (in the case of kiosks) or operator (in the case of POS) experience, our recommendation is to call Transaction Validate every time the user changes the offers and/or rewards contained in the basket. If network latency is an issue, integrators have the option to call this endpoint only once prior to payment. If Transaction Validate does not return errors, the loyalty transaction is expected to succeed in the last step below.

  • If the guest has made changes to rewards in their basket, call the Transaction Update (Loyalty API v1 - Update) endpoint with a status of PENDING, which will update the guest’s loyalty points balance. Note that the Transaction Update endpoint returns less detailed error information than Transaction Validate in case it fails, which means they need to be called separately.

  • Collect payment from the guest

  • Call the Transaction Update endpoint with a status of CLAIMED, which will close the loyalty transaction and permanently alter the guest's loyalty point balance.

  • Note that CLAIMED transactions can still be updated to VOID later, in case there is a refund issued to the guest (in which case the loyalty point updates will be reverted).

Testing

Please use this Postman collection for testing purposes:

 

  • No labels