...
Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Brands and markets want either their pre-existing or new kiosk implementations to work within the in-store loyalty experience. The kiosk user experience will have some slight nuances that we need to account for relating to the Loyalty APIs how Kiosks integrate with them.
Desired Kiosk User Flow
User identifies themselves as a loyalty user at kiosk using identification mechanism (i.e. 6-digit short, code, QR code, etc.)
The identification may include pre-selecting rewards and/or offers within the app similar to the in-store loyalty experience
Upon successful identification:
Any pre-selected rewards and/or offers are injected into the Kiosk order
User’s information is populated within the Kiosk (i.e. name, points balance)
User is able to proceed with placing their order by selecting desired items/combos
User is able to browse and select additional rewards they wish to redeem
Kiosk will display rewards based on user’s available point balance
User completes order at Kiosk
User picks up food at pick-up counter
General API Guidelines
Region {reg}
variables:
euc1
EU Timezone Marketsapse1
APAC Timezone Marketseuw3
Iberia Timezone Market
Environment {env}
variables:
dev
staging
qa
prod
Brand {brand}
variables:
bk
plk
fhs
All API requests should include the following in the header:
x-region
field. The value passed in this field should be the 2-character iso country code.x-api-key
field. The value passed in this field will be an environment, vendor and brand specific API key.x-user-datetime
field. The value passed in this field should be the local iso datetime string.
More Information on fields below:
"productType": "reward" or offer
Endpoints
Identify (POST)
Use Case: Successfully identify the loyalty user along with any potential rewards/offers that they had pre-selected within the app.
...