How can we help?

Search for answers to your questions by entering keywords in the search bar, or click through the categories of the knowledge base below.

ASF Check-In Integration Support


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:

Check-In Status Reason





No account issues present

Not Allowed


Member is not allowed due to account issues.



Account is canceled

Inactive Card


Cardholder is inactive



Prospect is deactivated



Account is expired

Expired Add On Payment Method


Account has an add-on payment method that is expired.

Expired Membership Payment Method


Account has a membership payment method that is expired.



Account has a membership freeze that blocks access.

Past Due Graced


Account is past due but within the grace period.

Membership Expiring


Account’s membership is expiring within the set threshold.

Missing Photo


Member does not have a photo present.

Out Of Visits


Prospect has run out of eligible visits.

Past Due


Account is past due. 

Card Code Restriction


Account’s card code does not have access at the current time based on configured card code restrictions.



Account is returned.

Recent Check-In


A recent check-in occurred on the account within the club-defined timeframe.

No access to location


Member does not have access to the location being checked into.

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

Type Issue
1 Past Due
2 Access Frozen
3 Canceled
4 Expired
5 Returned
6 Inactive





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



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

Type Issue
1 Past Due
2 Access Frozen
3 Canceled
4 Expired
5 Returned
6 Inactive


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 } ] } ],












Was this article helpful?
0 out of 0 found this helpful


Powered by Zendesk