How can we help?

ASF has several API's available to support third-party check-in integrations for door access. Our recommendations on how to use the data available in the API when completing a check-in are below.

To request access to our APIs for your third party, please reach out to ASF support. 

Checking in a Member (coming soon!)

To check in a member via API, the POST /api/v2/{clientId}/checkin should be used.

This API will both validate the member can access the club and check them in.  We recommend completing as many check-ins as possible in real-time using this check-in API to ensure you are getting the most up-to-date issues or alerts on an account. 

Submitting the Check-in

The following types of barcodes are supported for both members and prospects when posting a barcode to ASF:

1. ASF User ID (account number + sequence)
2. Alternate ID

Interpreting the Response

The POST response will indicate if the member should be allowed in the club. An example API response is below:

    {
      "clientId": 11010,
      "userId": "1689982-02",
      "altAccountNumber": "",
      "checkinDate": "2022-05-12T17:29:28.000Z",
      "source": "Club OS",
      "sourceNote": "Front Door Philadelphia"
      "allowEntry": false,
      "checkinStatus": "Problem",
      "checkinStatusReason": "Past Due"
      "alerts": [
          {
            "alertType": 1,
            "message": "Past Due",
            "alertDate": "2024-04-04T14:49:20.818Z",
            "allowDoorAccess": false
          }
    }

To confirm if a member should be granted access to the club on check-in, the `allowEntry` field should be used. This will provide a summary of all issues on the account to indicate overall access status. 

allowEntry: false = Member should not be granted access to the club

allowEntry: true = Member should be granted access to the club

The checkInStatus will indicate one of the following based on the account's current state:

1. Valid: Indicates no issues are present on the account. 
2. Warning: Indicates an issue is present on the account that does not block door access but should trigger a warning to the member. 
3. Problem: Indicates a high-priority issue is present on the account that blocks door access.

The checkInStatusReason will provide additional information to indicate why the member was blocked or which warning is present. 

The following reasons may exist:

*Club-defined alerts can be configured by the club to optionally display a warning or block access and will vary based on the clubs chosen configuration. 

The alerts object will provide additional information for some problem alerts to help indicate the issue present and when the alert started. Please note, not all attendance problems will appear in alerts object. 

Types of Alerts (Note: additional alerts may be added in the future)

Validating a Member prior to Check-in

When storing data to be used in cases where internet access is unavailable, we recommend using the data provided in the response from the GET /users request.  This is always included when pulling an individual user (e.g. GET /users/{id}) but can also be included when pulling lists of members by specifying includeAlerts = true as a query parameter.

The following information should be used to validate club access:

1. Alerts
2. Location Access

Alerts

• If any alerts are present  on a member in the API response from GET /users where allowDoorAccess = false the member should not be able to access the club.  
  
  • If multiple alerts are present, they will be shown in priority order, we typically recommend exposing the first alert to the user for information on why the check-in was blocked.
• When looking at the member record, if no blocking alerts are present but an alert is present that includes allowDoorAccess = true, this indicates a warning alert. This means that the member should not be blocked from accessing the club but has a warning issue present. You may choose to expose this alert to the club if desired.  

Types of Alerts (Note: additional alerts may be added in the future)

Location Access

The clientAccess object should be used when determine which locations a member can access. If a location is not listed in the clientAccess object for the member then the member does not have access to that location.  

* Please note, the singleClientAccess and reciprocalClient fields available in the API will soon be deprecated and should not be referenced.

Sample clientAccess object with alerts:

{
  "result": {
    "userData": [
      {
        "clientId": 4005,
        "firstName": "John",
        "lastName": "Smith",
        "accountNumber": 1423553,
        "userId": "1423553-01",
        "altAccountNumber": "12345",
        "status": "A",
        "role": "Member",
        "clientAccess": [
          {
            "id": 40051,
            "name": "ASF Club"
          },
          {
            "id": 40052,
            "name": "ASF Club Two"
          },

        ],
        "alerts": [
          {
            "alertType": 1,
            "message": "Past Due",
            "alertDate": "2024-06-11T22:24:53.865Z",
            "allowDoorAccess": true
          }
        ]
      }
    ],