PassEntry API (v1)

Download OpenAPI specification:Download

Getting Started

Welcome to Passentry

PassEntry API is an OpenAPI 3.1.0 compliant REST API with predictable URLs, JSON request bodies, standard HTTP response codes, authentication, and verbs. This documentation describes the functionality of our system available for integration with your business.

API Host https://api.passentry.com

Authentication

The PassEntry API uses API keys to authenticate requests. You can view and manage your API keys in Developer tools in the PassEntry Dashboard

Your API keys carry many privileges, so be sure to keep them secure. Don't share your secret API keys in publicly accessible areas such as GitHub, client-side code, and so forth.

Authentication to the API is performed with Bearer authentication. These tokens must be attached to the Authorization header of the request.

Example: "Authorization": "Bearer {API KEY}"

You must make all API calls over HTTPS. Calls that you make over plain HTTP will fail. API requests without authentication will also fail.

Responses

PassEntry API responses are generally in JSON API format, which provides a consistent standard for formatting responses in JSON, including a top-level data object and optional included and meta objects.

Errors

PassEntry uses conventional HTTP response codes to indicate the success or failure of an API request. In general: Codes in the 2xx range indicate success. Codes in the 4xx range indicate an error that failed given the information provided (e.g., a required parameter was omitted, syntax error, etc.). Codes in the 5xx range indicate an error with PassEntry's servers (these are rare).

Some 4xx errors include text that briefly explains the error reported.

Entities

What are entities?

Entities serve as subdivisions within an organization, designed to help larger clients such as aggregators or resellers manage their operations more effectively. Each entity can represent a different department or business unit within the larger organization, enabling detailed segmentation and breakdowns.

A common use case of having multiple entities is separating the passes in the Wallet (Most commonly an issue in Apple Wallet) as passes from different entities are not grouped in the Wallet.

All organisations have one entity by default. For most organisations, this is sufficient. If you would like to create additional entities, please contact PassEntry.

Example

An organisation, "PassEntry Enterprise" has 2 business units, "PassEntry Supermarket" and "PassEntry Coffee". In order to keep their information and data separate, they have 2 Entities, each with their own Pass Templates, Passes...etc

List entities

Securityapi_key
Responses
200

Successful

401

Error: Unauthorized

get/api/v1/entities
Request samples
Response samples
application/json
{}

Show Entity

Securityapi_key
Request
path Parameters
id
required
string

Entity ID

Responses
200

Successful

401

Error: Unauthorized

404

Error: Not Found

get/api/v1/entities/{id}
Request samples
Response samples
application/json
{}

Pass Templates

Pass templates

Before creating passes using the PassEntry API, it is necessary to have a pass template built. A template serves as a blueprint for your passes and includes various components such as fields, colours, images and value keys.

Create pass template

To create a pass template, you can do so directly from the Dashboard, in the Pass Templates page. Click the button 'Create Pass Template' in the top right corner (direct link: https://passentry.com/pass-templates/create).

Once created, the pass template will be shown in the Pass Templates page.

See pass templates list

All pass templates are displayed in the Pass Templates page of your Dashboard (direct link: https://passentry.com/pass-templates).

Show Pass TemplateDeprecated

Securityapi_key
Request
path Parameters
pass_template_uuid
required
string

pass_template_uuid

Responses
200

successful

401

Error: Unauthorized

404

Error: Not Found

get/api/v1/pass_templates/{pass_template_uuid}
Request samples
Response samples
application/json
{
  • "data": {
    }
}

Events

Show event

Securityapi_key
Request
path Parameters
event_uuid
required
string

event_uuid

Responses
200

Successful

401

Error: Unauthorized

404

Error: Not Found

get/api/v1/events/{event_uuid}
Request samples
Response samples
application/json
{
  • "data": {
    }
}

Update event

Securityapi_key
Request
path Parameters
event_uuid
required
string

event_uuid

Request Body schema: application/json
object
Responses
200

successful

401

Error: Unauthorized

422

Error: Unprocessable Entity

patch/api/v1/events/{event_uuid}
Request samples
application/json
{
  • "event": {
    }
}
Response samples
application/json
{
  • "data": {
    }
}

Create event

Securityapi_key
Request
path Parameters
entity_id
required
string

entity_id

Request Body schema: application/json
object
Responses
201

Created

401

Error: Unauthorized

422

Error: Unprocessable Entity

post/api/v1/entities/{entity_id}/events
Request samples
application/json
{
  • "event": {
    }
}
Response samples
application/json
{
  • "data": {
    }
}

Passes


Notifications

PassEntry supports wallet-native push notifications on both the Apple and Google Wallet.

Use notifications to deliver timely and relevant updates to your customers, such as when the time for an event has changed or that their membership is about to expire. A push notification message will appear on the lock screen and will be stored on the back of the pass as the "Latest Update".

Best practices

Google currently limits their push notifications to 3 per day per pass, if you go over this quota, the passholder will not receive a push notification on their lock screen, but it will update the "Latest Update" on the back of the pass.

Apple limits their push notifications to 10 per day and may sometimes not show push notifications if sent within a very short interval (seconds between notifications)

We suggest limiting the maximum number of notifications per day per pass to 3

Using PassEntry's Download Page to Deliver Passes

When creating a pass, we return a JSON object with pass attributes and timestamps. Within this object, we include a downloadUrl, unique to each pass, which when clicked by the end user will open a generic pass download page, a web view hosted by PassEntry on download.passentry.com.

As at this stage, the passholder's device type is unknown, one of the purposes of this download page is to detect the user's device and deliver either an Apple Wallet pass or Google Wallet pass. When the download page is opened on a device other than an iPhone or Android phone, it will display a QR code directing the user to the same URL, in order to direct them to open the download page on a mobile device.

Using this download page enables simple distribution of passes to your customers via a generic, dynamic link. As a best practice, we suggest putting the downloadUrl behind a button or redirecting the user to it at a desired point in their user journey.

Using 'Direct' Pass Source Delivery

In some cases, use of the download page is not a viable option, such as when provisioning the pass from within an app, or when wanting to directly deliver the pass from within a web page, without redirecting the user to PassEntry's download page.

In order for this to be possible, you must know the device type when creating the pass. When delivering the pass from within an app, the device type will already be known. When delivering from a web page, there are a number of scripts that can be used to detect the device type and request the correct pass source.

Here is a sample script:

// JavaScript
const getMobileOS = () => {
  const userAgent = navigator.userAgent || navigator.vendor || window.opera;
  if (/android/i.test(userAgent)) {
    return "Android";
  } else if (/iPhone/i.test(userAgent)) {
    return "iPhone";
  }
  return "Other";
};

// Example usage
const mobileOS = getMobileOS();
console.log(`This page is opened on: ${mobileOS}`);

Once the device is known, request and deliver the correct Pass Source. To request the Pass Source, include the ?includePassSource query parameter in your POST /passes/ or GET /passes/:id request. This parameter accepts apple or google as options. For more details, review the API documentation for these endpoints.

If valid, the response will include the pass attributes in JSON, alongside a passSource object. It will only return the passSource object in the response if the selected pass is not currently active in a device.

Delivering a Google Wallet Pass

The passSource object will contain a key, googleDownloadUrl, containing a unique URL, which when opened on an Android device, will prompt the user to add their pass to their Google Wallet. As the Google Wallet is linked to an individual Google Account, the user will be prompted to log in to their Google Account if they are not already logged in and to download the Google Wallet if they have not already done so.

The googleDownloadUrl works best when placed behind Google's "Add to Google Wallet" button. Here are the brand guidelines and assets provided by Google:

Add to Google Wallet

Delivering an Apple Wallet Pass

Apple requires the pass source to be delivered as a file with a .pkpass extension. The passSource object will contain a key, appleBase64, containing the .pkpass file encoded in base64. Decode the base64, save it to a file with the .pkpass extension, and deliver this to the user. When an iPhone detects a .pkpass file, it will prompt the user to add it to their Apple Wallet. Deliver the pass when the user clicks Apple's "Add to Apple Wallet" button. Here are the brand guidelines and assets provided by Apple:

Add to Apple Wallet

Send Notification

Securityapi_key
Request
path Parameters
id
required
string

Pass UUID or External ID

Request Body schema: application/json
object
Responses
200

Succesful

400

Error: Bad Request

401

Error: Unauthorized

404

Error: Not Found

post/api/v1/passes/{id}/notification
Request samples
application/json
{
  • "notification": {
    }
}
Response samples
application/json
{
  • "data": {
    },
  • "meta": {
    }
}

Create pass

Securityapi_key
Request
query Parameters
passTemplate
required
string

Identifies the pass template to use

extId
string

External ID used to identify the pass. Optional

includePassDesign
boolean

If true, includes the pass design in the response

includePassSource
string

Used when delivering the pass directly to the passholder, without using PassEntry's download page. Choose one of Apple/Google, includes the pass source in the response. The passSource object is only included if the pass is not currently 'active'

Enum: "apple" "google"
Request Body schema: application/json
object
message
string

Push Notification message to display. If present, response will include X-Notification-Status header

passAction
string

Only available when updating the pass.

Enum Value Description
deactivate

Deactivates the pass, setting it to 'expired' in the wallet. When in this state, pass can receive updates but does not receive Apple notifications.

reactivate

Reactivates the pass, setting it to 'active' in the wallet. In the case of Apple passes, the pass will remain in the 'expired' passes section of the wallet, user will need to manually select 'unhide' to move passes to the main passes view

Array of objects (location) <= 10

Array of locations, currently only available on Apple devices, due to Android device restrictions. Maximum of 10 locations

Array of objects (beacon) <= 10

Array of beacons, currently only available on Apple devices, due to Android device restrictions. Maximum of 10 beacons

groupTag
string

Tag used for grouping passes

Responses
200

Successful

400

Error: Bad Request

401

Error: Unauthorized

404

Error: Not Found

post/api/v1/passes
Request samples
application/json
{
  • "pass": {
    },
  • "locations": [
    ]
}
Response samples
application/json
{
  • "data": {
    }
}

List passes

Securityapi_key
Request
query Parameters
perPage
integer

Record limiter per page. Default is 100

status
string

Filter passes by status

Enum: "issued" "active" "removed" "deactivated"
deviceType
string

Filter passes by device type

Enum: "android" "iphone"
groupTag
string

Filter passes by group tag

passTemplateUuid
string

Filter passes by pass template UUID

passTemplateName
string

Filter passes by pass template name. Must be URL encoded

eventUuid
string

Filter passes by event UUID

eventName
string

Filter passes by event name. Must be URL encoded

createdAfter
string

Returns passes created after given datetime. Format is ISO 8601

createdBefore
string

Returns passes created before given datetime. Format is ISO 8601. Can be combined with createdBefore parameter

fields
string

Returns a partial response (Sparse fieldset) per record, instead of the whole record. Set one or many comma separated record attributes

includePassDesign
boolean

If true, includes the pass design in the response

Responses
200

Successful

400

Error: Bad Request

401

Error: Unauthorized

get/api/v1/passes
Request samples
Response samples
application/json
{
  • "data": [
    ],
  • "meta": {
    },
  • "links": {
    }
}

Update pass

Securityapi_key
Request
path Parameters
id
required
string

Pass UUID or External ID

query Parameters
includePassDesign
boolean

If true, includes the pass design in the response

Request Body schema: application/json
object
message
string

Push Notification message to display. If present, response will include X-Notification-Status header

passAction
string

Only available when updating the pass.

Enum Value Description
deactivate

Deactivates the pass, setting it to 'expired' in the wallet. When in this state, pass can receive updates but does not receive Apple notifications.

reactivate

Reactivates the pass, setting it to 'active' in the wallet. In the case of Apple passes, the pass will remain in the 'expired' passes section of the wallet, user will need to manually select 'unhide' to move passes to the main passes view

Array of objects (location) <= 10

Array of locations, currently only available on Apple devices, due to Android device restrictions. Maximum of 10 locations

Array of objects (beacon) <= 10

Array of beacons, currently only available on Apple devices, due to Android device restrictions. Maximum of 10 beacons

groupTag
string

Tag used for grouping passes

Responses
200

Successful

400

Error: Bad Request

401

Error: Unauthorized

404

Error: Not Found

patch/api/v1/passes/{id}
Request samples
application/json
{
  • "pass": {
    },
  • "message": "Your pass details have been updated. Click to show pass",
  • "locations": [
    ]
}
Response samples
application/json
{
  • "data": {
    },
  • "meta": {
    }
}

Get pass

Securityapi_key
Request
path Parameters
id
required
string

Pass UUID or External ID

query Parameters
includePassDesign
boolean

If true, includes the pass design in the response

includePassSource
string

Used when delivering the pass directly to the passholder, without using PassEntry's download page. Choose one of Apple/Google, includes the pass source in the response. The passSource object is only included if the pass is not currently 'active'

Enum: "apple" "google"
Responses
200

Successful

401

Error: Unauthorized

404

Error: Not Found

get/api/v1/passes/{id}
Request samples
Response samples
application/json
{
  • "data": {
    }
}

Loyalty

PassEntry provides a number of RESTful endpoints for interacting and manipulating passes created under the Loyalty vertical.
This includes but is not limited to: Loyalty Cards, Gift Cards, Coupons, Memberships…

Terminology

Balance: This can represent loyalty points, stamps, credit, and more in an integer type. Balance can be accumulated or used. Balance is stored in our database and represented on the pass.

POS System: handles in store sales transactions, inventory management, and reporting

Loyalty Program: This is implemented externally to PassEntry, is where the loyalty behaviour is handled and loyalty/customer data is stored. Ideally, this would be closely integrated with the POS system, in order to allow for seamless tracking of purchases and points. As a best practice, any loyalty data relevant to a pass must always be mirrored in the loyalty program.

Payment Terminal: where payment is made, can also be used to read the loyalty pass and thus identify the customer

Enabling loyalty balance

To allow interacting with your passes using the Loyalty API, the first step is to ensure that the parent template has loyalty balance enabled. Once this is done, you must choose how you want the balance to be represented on the pass, set at the pass template level. We currently offer support for integer and decimal types.

  • Integer: Choose this if your balance is represented as whole numbers. Eg: 3, 42, 9000. The loyalty balance will appear as an integer in our responses to the loyalty API, and any numeric value sent in a request will be coerced to an integer. The value on the pass will be represented as an integer.
  • Decimal: We support up to 2 decimal places. Eg: 3.14, 10.95, 100000.34. The loyalty balance will appear as a float in our responses to the loyalty API. When making requests, format the number as a float with no more than 2 decimal places. When displaying the value on the pass, it will be represented using thousand separators with 2 decimal places. (100,000.34)

What does a loyalty integration with PassEntry look like?

Example: PassEntry Coffee has a loyalty program. Every £10 spent, a customer receives 1 Point
When a customer has received 5 points they are able to get £5 off on their order total

Distributing a loyalty pass

  1. A loyalty pass is created and distributed to a customer with an ext_id equivalent to customer in the loyalty program

  2. The loyalty pass balance on this loyalty pass is 0. This is represented on the loyalty pass as Points 0 and is stored on the loyalty program.

  3. When the customer makes a purchase in store and presents their device to make payment, the reader identifies their loyalty pass and sends both the loyalty pass ext_id and the loyalty pass balance to the POS

Accumulating balance

  1. The POS system takes payment, and updates the loyalty pass with a balance equal to a value determined by the loyalty program, alongside an optional push notification.

  2. In this example, the customer has spent £20, so the the balance is increased by 2 points and the customer receives Thank you for your order. You've earned 2 points! as a push notification.

Receiving a reward

  1. The POS system takes £10 payment and customer balance is increased by 1 point.

  2. As the threshold of 5 points has been reached, as determined by the loyalty program, the customer is sent a push notification Congratulations! You've got £5 off on your next order!

  3. The pass design can be updated via the /passes/ endpoint so that the £5 off reward appears on the loyalty pass design to inform the customer of their reward

Redeeming a reward

  1. The POS system is ready to receive payment of £8

  2. The customer presents their device, and their loyalty pass ext_id and balance are sent to the POS system, identifying the customer to the loyalty program

  3. The loyalty program detects that the customer has 5 points and is thus entitled to a £5 off discount

  4. The POS system prompts the user to redeem their £5 off! reward via a Would you like get £5 off on this order? prompt (Optional: rewards can be applied automatically as determined by the loyalty program)

  5. The transaction amount on the payment terminal is updated to £3

  6. The customer makes payment

  7. The reward is removed from the loyalty pass alongside a You've used your £5 off discount! push notification

Resetting the balance (Optional)

  1. At this stage, the loyalty balance can be reset to 0 points

Get loyalty balance

Securityapi_key
Request
path Parameters
id
required
string

Pass UUID or External ID

query Parameters
includePassDesign
boolean

If true, includes the pass design in the response

Responses
200

successful

401

Error: Unauthorized

404

Error: Not Found

412

Error: Precondition Failed

get/api/v1/loyalty/{id}
Request samples
Response samples
application/json
{
  • "data": {
    },
  • "meta": {
    }
}

Update loyalty balance

Securityapi_key
Request
path Parameters
id
required
string

Pass UUID or External ID

query Parameters
includePassDesign
boolean

If true, includes the pass design in the response

Request Body schema: application/json
balance
integer

If integer is positive, balance is added. If negative, balance is subtracted. Cannot be used with overrideBalance key

overrideBalance
integer

Override the balance and set it to this value. Cannot be used with balance key

message
string

Push Notification message to display. Only used if pass is active. Use alongside balance or overrideBalance keys

Responses
200

successful

patch/api/v1/loyalty/{id}
Request samples
application/json
{
  • "balance": 10
}
Response samples
application/json
{
  • "data": {
    },
  • "meta": {
    }
}

Webhooks

Incoming Webhooks with PassEntry

Overview

When building integrations with PassEntry, you might want your application to receive events as they occur, so that your backend systems can execute actions accordingly.

To enable webhooks, you must first register a valid HTTPS URL, and subscribe to the events you want to be notified by. To do this, please visit the Webhook section on the PassEntry dashboard.

Setting Up Your Webhook Endpoint

  • HTTPS Requirement: Ensure your endpoint is a valid HTTPS URL and the path can receive POST requests.

Receiving Webhook Events

  • Event Notification: Upon the occurrence of a subscribed event, PassEntry will send a JSON payload to your endpoint, detailing the event type, timestamp, and relevant information.

Security Measures

We implement a number of security measures to guarantee any interactions between PassEntry and your system are verified and authentic.

  • Secret Key: When configuring your webhook endpoint, you will be provided a secret key, which PassEntry will use to sign any outbound webhooks. You must store this securely. If you believe your secret key has been compromised, you have the option to rotate your secret key. This will immediately invalidate the previous secret key and sign all subsequent webhooks with the new key

  • Timestamp: Each webhook payload includes a timestamp, serving as a safeguard against replay attacks.

  • HMAC-SHA256 Signature: Every outgoing webhook includes an HMAC signature. The signature is included in the X-Webhook-Signature header and is generated using the webhook payload and the shared secret key. To verify that the webhook is authentic, you can encrypt the webhook payload using the SHA-256 encryption algorithm and your secret key. If your generated signature matches the signature included in the X-Webhook-Signature header, you can confirm that the webhook is authentic.

Reliability and Retries

  • Asynchronous Delivery: Webhooks include a timestamp to reflect the actual event time.

  • Retry Mechanism: Failures in delivery due to network issues, SSL problems, or non-2xx HTTP responses will trigger retries. PassEntry retries delivery up to 10 times over 3 days, using exponential backoff.

Responding to Webhooks

  • Success Responses: Please ensure your endpoint returns a status code within the 200-299 range. Any code outside this range is considered an error, prompting retries.

  • Response Body: While optional, you may return a response body.

Example Success Response

HTTP Status: 200
Content-Type: application/json

{
  "status": "ok"
}

Pass InstalledWebhook

Webhook triggered when a pass is added to the wallet by user

SecurityWebhookSignature
Request
Request Body schema: application/json
object
Array of serializedPassObject (object) or serializedPassTapObject (object) or serializedReaderObject (object)
Responses
200

Return a 200 status to indicate that the data was received successfully

Request samples
application/json
{
  • "data": {
    },
  • "included": [
    ]
}
Response samples
application/json
{
  • "status": "ok"
}

Pass RemovedWebhook

Webhook triggered when a pass is removed from the wallet by user

SecurityWebhookSignature
Request
Request Body schema: application/json
object
Array of serializedPassObject (object) or serializedPassTapObject (object) or serializedReaderObject (object)
Responses
200

Return a 200 status to indicate that the data was received successfully

Request samples
application/json
{
  • "data": {
    },
  • "included": [
    ]
}
Response samples
application/json
{
  • "status": "ok"
}

Pass TappedWebhook

Webhook triggered when an NFC pass is tapped on a reader

SecurityWebhookSignature
Request
Request Body schema: application/json
object
Array of serializedPassObject (object) or serializedPassTapObject (object) or serializedReaderObject (object)
Responses
200

Return a 200 status to indicate that the data was received successfully

Request samples
application/json
{
  • "data": {
    },
  • "included": [
    ]
}
Response samples
application/json
{
  • "status": "ok"
}

Readers

Readers can be used for a variety of use cases, to validate access, redeem loyalty, claim discounts, identify the user and much more.

NFC

PassEntry's passes are NFC enabled, which allow you to set an NFC 'value' behind every pass. This value defaults to the UUID of the pass, or can be set to a custom value. This NFC value is encrypted, and can only be generated by PassEntry. In order for the NFC value to be read, an NFC reader must be configured. To do this, two things are required, a pass identifier, which tells the reader which passes to request the device for when "tapped", and a private key, which allows the reader to decrypt the NFC value.

Our system supports two types of Readers: VTAP Readers and PassEntry Reader App. Both types can be configured through the Passentry Dashboard or via API requests.

Below, we provide an overview of each reader type, the configuration process, and additional setup information.

VTAP Readers

VTAP Readers come in a range of form factors, from boxed, countertop devices to embedded hardware that can be integrated in existing platforms. The NFC value can be transmitted over the internet, or over wire through USB, RS-232, RS-485, Wiegand and more.

Configuration:

Setting up a VTAP Reader consists of two parts:

  1. Creating a Reader on Passentry: You need to provide the following information:
  • Name: A friendly display name for the reader
  • UUID: A unique identifier for the reader, this must be the "Reader Serial" provided by Dot Origin
  • Type: Should be set to VtapReader
  1. Setting up the Device on VTAP Website: After creating the reader on Passentry, retrieve the required configuration information and use it to set up the device on the VTAP website. More detailed instructions are provided in the guide.

PassEntry Reader App

PassEntry Reader is a software application available for download from the Google Play Store, MAXSTORE, and Sunmi App Store. This reader offers additional functionality and settings for scanning NFC passes, QR codes/barcodes, Mifare Classic NFC cards, and more. It can perform specific actions such as scanning taps, redeeming/adding points, and adding stamps. For more information, please contact PassEntry.

Get reader

Securityapi_key
Request
path Parameters
id
required
string

Reader ID

Responses
200

Successful

401

Error: Unauthorized

404

Error: Not Found

get/api/v1/readers/{id}
Request samples
Response samples
application/json
{
  • "data": {
    }
}

Update reader

Securityapi_key
Request
path Parameters
id
required
string

Reader ID

Request Body schema: application/json
object
Responses
200

successful

401

Error: Unauthorized

422

Error: Unprocessable Entity

patch/api/v1/readers/{id}
Request samples
application/json
{
  • "reader": {
    }
}
Response samples
application/json
{
  • "data": {
    }
}

Create reader

Securityapi_key
Request
path Parameters
entity_id
required
string

entity_id

Request Body schema: application/json
object
Responses
201

Created

401

Error: Unauthorized

422

Error: Unprocessable Entity

post/api/v1/entities/{entity_id}/readers
Request samples
application/json
{
  • "reader": {
    }
}
Response samples
application/json
{
  • "data": {
    }
}

Get reader configuration

Securityapi_key
Request
path Parameters
entity_id
required
string

entity_id

Responses
200

Successful

401

Error: Unauthorized

404

Error: Not Found

get/api/v1/entities/{entity_id}/readerConfiguration
Request samples
Response samples
application/json
{
  • "data": {
    }
}

Apple Geofencing

Overview

This document outlines the implementation of geofencing and iBeacon technology to enhance customer engagement through targeted notifications based on location proximity.

Currently, only Apple Wallet passes support this feature due to Google Wallet constraints.

Geofence Notifications

  • When a user enters a geofenced area, a notification appears on the lock screen, displaying a preview of the pass from the wallet app along with any set geofence message.
  • Tapping the notification opens the pass in the wallet app, facilitating quick access to barcodes or NFC validation.
  • Geofence notifications are passive, meaning the system does not notify PassEntry when a user enters a geofence. This design respects privacy and security considerations.

Note: When setting 2 or more geofences in close proximity, there may be a delay in the notification appearing when moving between geofences. The device implements a cooldown period to ensure that the user has left the previous geofence before entering the next one.

Locations

  • Utilizes exact coordinates (latitude and longitude) to define the targeted area.
  • The radius for geofencing can be set between 10 and 1000 meters (depending on pass type). This allows you to tailor the geofenced area to your specific needs, such as covering the area of a small store or a larger outdoor venue.
  • Each pass can include up to 10 geofenced locations. For more extensive coverage, consider using beacons.
  • PassEntry is not able to track the exact location of the user, we do not have access to the user's location data, as this never leaves the device.

Beacons

iBeacons are a technology standard developed by Apple that allows mobile apps to listen for signals from beacons in the physical world and react accordingly.
The technology is based on Bluetooth Low Energy (BLE) proximity sensing, which enables a device to perform actions when in close proximity to a beacon. PassEntry is not able to track the exact location of the user, we do not have access to the user's location data, as this never leaves the device.

Learn more about beacons here: iBeacon

If you have a large number of location you would like to enable geofence capabilities for, here's an example:

Use Case: PassEntry Coffee Chain

  • Scenario: PassEntry Coffee, a chain with 100 locations across London, Dubai, and Singapore, uses iBeacons to offer location-based promotions.
  • Each location is equipped with two beacons: one in the bakery section and another in the cafe section.
  • The PassEntry Coffee loyalty pass incorporates different campaigns across regions, utilizing the same UUID for all beacons but varying Major and Minor values for location and section identification.
  • In total, PassEntry Coffee would purchase and configure 200 ibeacons (100 locations x 2 sections).

Configuration Example

  • UUID: All beacons use E2C56DB5-DFFB-48D2-B060-D0F5A71096E0.
  • Major: Represents the city (e.g., 1 for London, 2 for Dubai).
  • Minor: Specifies the section within a location (e.g., 1 for the bakery, 2 for the cafe).

In this example: PassEntry Coffee would configure their 200 beacons like so:

London (50 locations): 
  Bakery Section beacons: 
    uuid: E2C56DB5-DFFB-48D2-B060-D0F5A71096E0 
    major: 1 
    minor: 1 
    name: 'london-bakery' 
  Cafe Section beacons: 
    uuid: E2C56DB5-DFFB-48D2-B060-D0F5A71096E0 
    major: 1 
    minor: 2 
    name: 'london-cafe' 

Dubai (30 locations): 
  Bakery Section beacons: 
    uuid: E2C56DB5-DFFB-48D2-B060-D0F5A71096E0 
    major: 2 
    minor: 1 
    name: 'dubai-bakery' 
  Cafe Section beacons: 
    uuid: E2C56DB5-DFFB-48D2-B060-D0F5A71096E0 
    major: 2 
    minor: 2 
    name: 'dubai-cafe' 

Singapore (20 locations): 
  Bakery Section beacons: 
    uuid: E2C56DB5-DFFB-48D2-B060-D0F5A71096E0 
    major: 3 
    minor: 1 
    name: 'singapore-section' 
  Cafe Section beacons: 
    uuid: E2C56DB5-DFFB-48D2-B060-D0F5A71096E0 
    major: 3 
    minor: 2 
    name: 'singapore-cafe'

When building the pass via the PassEntry API, the following JSON structure would be used to define the beacons:

{
  "beacons": [
      {
      "proximity_uuid": "E2C56DB5-DFFB-48D2-B060-D0F5A71096E0",
      "major": 1,
      "minor": 1, 
      "message": "£10 off on cakes!",
      "name": "london-bakery"
    }, {
      "proximity_uuid": "E2C56DB5-DFFB-48D2-B060-D0F5A71096E0",
      "major": 1,
      "minor": 2, 
      "message": "Buy one get one free juice",
      "name": "london-cafe"
    }, {
      "proximity_uuid": "E2C56DB5-DFFB-48D2-B060-D0F5A71096E0",
      "major": 2,
      "minor": 1, 
      "message": "AED 20 off on cakes!",
      "name": "dubai-bakery"
    }, {
      "proximity_uuid": "E2C56DB5-DFFB-48D2-B060-D0F5A71096E0",
      "major": 2,
      "minor": 2,
      "message": "Try our pumpkin spice lattes!",
      "name": "dubai-cafe"
    }, {
      "proximity_uuid": "E2C56DB5-DFFB-48D2-B060-D0F5A71096E0",
      "major": 3,
      "minor": 1,
      "message": "$5 off on kuih lapis!",
      "name": "singapore-bakery"
    }, {
      "proximity_uuid": "E2C56DB5-DFFB-48D2-B060-D0F5A71096E0",
      "major": 3,
      "minor": 2, 
      "message": "Buy one get one free teh tarik!",
      "name": "singapore-cafe"
    }
  ]
}