This article will go over how to make an API call, from looking at which endpoint(s) to use, learning more about parameters and how to read API responses. Requirements -
Making An A P I call
1. Endpoints To make an API call you first want to determine which endpoint(s) you need to call depending on the end goal. Refer to the API Documentation and refer to the endpoint description to see what that endpoint can do.
2. Parameters Every API endpoint has a set of parameters that need to be included to make a call. Some parameters are required, some are optional, and every endpoint will have slightly different parameters. One parameter that is always required is the API Key field. To learn how to view & obtain an API key, click [here].
GET Parameter Examples For this endpoint, the API key and either Store ID or Chain ID are required - you won't need to input both Store ID and Chain ID:
POST Parameter Examples
For this endpoint, API key, user ID, store ID and schedule ID are required. AllowWaitList looks a little different because it's not required and isn't asking for an ID. In this situation the endpoint is looking for either true or false. If the class ends up being full when you make the API call do you want the user to go on the wait list? If so, then you'd type true in that field. It will default to false if the field is left blank when making the call.
PUT Parameter Examples For this endpoint API key, store ID and user ID are required fields. The PUT /users/{UserId} endpoint allows you to update information on an existing user account, so the other parameters are all user info fields that can be updated. The vendor will only input information into fields that they want to change on the user's account.
3. API Call, Request URL & Response Body
API Call After completing the parameters and clicking "Try It Out!", congrats! You've made an API call.
Request URL Underneath "Try It Out!" you'll see a section for Request URL. Asking vendors for the Request URL when they're having issues with an API call helps us troubleshoot because the URL shows what endpoint they're using & what parameters they used. An example is:
https://www.clubready.com/api/club/lead-types?ApiKey=ebb7df00-5065-468d-ae11-9f1bacded72f&StoreId=31...
Response Body On GET calls, the response body provides the data the vendor requested for through the endpoint. The response body will look a little different depending on which endpoint was used. If an API call is made to get a list of lead types available in a club, the response body will look like this:
{
"LeadTypes": [
{
"Id": 25838,
"Name": "Converted Leads",
"ChainId": 386
},
{
"Id": 38218,
"Name": "Cancelled Member",
"StoreId": 3101
}, {
"Id": 27447,
"Name": "Gilt City - March 2017",
"ChainId": 386
}
]
}
The ID is the lead type ID, the name is the name of the lead type, and the response body will return whether this is a Chain level lead type or a Store level lead type. HINT: this endpoint and response is important for vendors who need to update existing users lead type and/or who want to add a new prospect with a specific lead type and needs to obtain the ID.
On a POST API call you're adding new information into the system so the response body is general going to give you a true/false success message and the details of the new information. This is the response body of creating a new prospect:
{
"UserId": 73859483,
"Success": true,
"EmailSent": false,
"PackageAdded": false,
"StatusCode": 200,
"Message": "Success"
}
On a PUT API call, you're updating information into fields and the response body will either be "true" or "false". If false, that means the information did not update.