Customer Bound Access Quick Reference

Overview

This guide is a quick reference that lists the steps for accessing the customer information of the currently logged in user. In USTA parlance, this is 'Bound' access. In this mode, the customer UAID is bound to the session under which the user has logged in to USTA.com.  The token will restrict access to only data for this one UAID.

Integrating your application with USTA.com is easy. You can use any programming language or tool that supports HTTPS communications.  

Before Development

Before you begin development of your browser-based application, contact USTA to discuss what data you will need to access from USTA.  Credentials will be issued for use to connect via HTTP.

Credentials:

1. client id
2. client secret

Scope:

1. Read/Write
2. Which data

Environments:

1. Stage (preproduction)
2. Prod

Building Your Application

The following is a quick guide for accessing bound customer data.  More on the bound mode can be found on the API Reference page.  

It should be noted that the best use of this API is within the context of a browser-based application.  Because the customer UAID is bound to the token, it is safe to store in a cookie.

Step 1:  Retrieve a Credentials Token

The USTA bound access model is secured via the Janrain Identity Service.  You must pass in your unique email corresponding to the USTA account for which you would like to retrieve customer information.  Please note that the identity must pre-exist at Janrain before the call is made in order to authenticate and receive a credentials token.

If the email address does not exist at Janrain, there is no customer information to retrieve from USTA.

Headers

This API call uses Basic Authorization.  Use the supplied client_id and secret to generate a Basic Authentication token.  There are many online generators you can use for testing.  One is here.

HTTP Call

This is the API call.  Please note the difference in base urls:

Test:  https://stage-services.usta.com

Prod: https://services.usta.com

Result

The important info returned from this call are the following:

jti:  token that will be passed in subsequent calls

exprires_in: the Time To Live of the token

{
    "access_token": "eyJh...,
    "token_type": "bearer",
    "expires_in": 43199,
    "scope": "safeplay:status safeplay:details",
    "client_name": "ClubBling",
    "jti": "7b5f8ede-bbc1-4b2b-b127-a6f0e9dfb8cd"
}

Example

This example uses CURL from the command line.

Step 2:  Retrieve Approval Status Using JWT Token

This API call is used to retrieve a 'thumbs up/thumbs down' assessment of whether the provider is SafePlay approved.  This result is calculated based on the following criteria:

• Legal Agreement Date
• NCSI Status
• SafeSport Completion
• SafeSport Expiration

Headers

Data/Payload

Email is used as the unique identifier for looking up SafePlay status.

Result

The result is calculated summary status of true/false.

{
    "isApproved": false
}

Example

This example uses CURL from the command line.

Step 2:  Retrieve Approval Details Using JWT Token (Optional)

Similar to the call above, you can optionally see the inputs that went into the calculation of the isApproved call.

Headers

Data/Payload

Result

The result shows the current values associated with the inputs:

• Legal Agreement Date
• NCSI Status
• SafeSport Completion
• SafeSport Expiration

{
    "legalAgreementAcceptDate": "2019-05-14",
    "legalAgreementExpireDate": "2021-05-14",
    "legalAgreementStatus": "Accepted",
    "ncsiCheckTimestamp": "2019-06-28T12:03:04",
    "ncsiExpiryDate": "2019-06-19",
    "ncsiCheckStatus": "Expired",
    "safeSportCompleteDateTime": "2018-10-25T10:56:07",
    "safeSportExpiryDate": "2020-10-25",
    "safeSportStatus": "COMPLETE",
    "safePlayStatus": "EXPIRED",
    "safePlayStatusDisplayValue": "Expired"
}

Example

This example uses CURL from the command line.