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

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.

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.

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.

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

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).

---

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

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.

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

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

4. 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.

5. 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

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

6. 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!

7. 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

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

9. 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

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

11. 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)

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

13. The customer makes payment

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

Resetting the balance (Optional)

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

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.

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.

• 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.

• 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"
}

---

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 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

2. 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 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.