# Introduction

The Support Hub API is a REST API that covers all endpoints that you can use to communicate with your Support Hub account and without logging in to the Support Hub web application.

# HTTP Status Codes

HTTP Status Code Status Message Description
200 OK Everything worked as expected.
201 Created Resource was created successfully.
400 Bad Request The request was unacceptable, often due to missing a required parameter.
401 Unauthorized No valid API key provided.
403 Forbidden Accessing the resource is forbidden for this user.
404 Not Found The requested resource doesn't exist.
422 Unprocessable Entity Required fields are missing or cannot be processed.
500, 502, 503, 504 Server Errors Something went wrong on Support Hub's end.

# Rate Limit

The number of API calls per minute are based on the subscription plan you are currently subscribed on.

Subscription Plan Requests / minute
Basic 15
Starter 150
Standard 300
Elite 600

You can check your current rate limit status by looking at the following HTTP headers which are returned in response to every API request.

X-RateLimit-Limit: 150
X-RateLimit-Remaining: 140

In case if you hit the rate limit, an 429 Too Many Requests HTTP response will be returned from the API and the following headers will also be present in the response:

Retry-After: 50
X-RateLimit-Reset: 1572168550

The Retry-After header indicates how long you need to wait until you can send the next request and the X-RateLimit-Reset header is the exact timestamp when the rate limiting will be reseted so you can again send the request to the API.

# Authorization

Support Hub API uses the API key for authorization. You can find your API key from your profile section.

Any request that requires an authorized user expects this token to be supplied in the form of a Authorization header like so:

Authorization: Bearer {api_key}

When a API key has not been supplied, or the supplied API key is invalid, the API will return a 401 Unauthorized response with the following body:

    "message": "Unauthenticated."

# Error Handling

The API returns a variety of errors and each error will contain a message property with the info about the error itself. The most common type of errors are the validation errors that will always be formatted like following:

    "message": "The given data was invalid.",
    "errors": {
        "first_name": [
            "The first name field is required."
        "last_name": [
            "The last name field is required."
        "email": [
            "The email field is required."

# Pagination

Some endpoints will return data in a paginated list. A paginated response will look similar to this:

    "data": [
    "links": {
        "first": "https://yoursubdomain.support-hub.io/api/tickets?page=1",
        "last": "https://yoursubdomain.support-hub.io/api/tickets?page=1",
        "prev": null,
        "next": null
    "meta": {
        "current_page": 1,
        "from": 1,
        "last_page": 1,
        "path": "http://yoursubdomain.support-hub.io/api/tickets",
        "per_page": 15,
        "to": 15,
        "total": 15

As per the example above, each paginated response will have the data array, which contains all the items from the specific page, a links object with full URLs for fetching first, last, prev and next pages, and the meta object which contains all the info about the resource you are paginating.

Some endpoints allow you to specific number of records that you want to receive per page. To achieve that you can append the per_page=X parameter to the URL of the request. For example, if you want to request 50 customers per page, the URL parameters should look like the following:


Pagination limit is set to 100 for most resources which means that you cannot request more than 100 records per page. If you provide a larger number, it will be ignored and 100 records per page will be returned.

To request a different page, just append the page=X parameter to the URL. For our customers example above, you can get the second page like following:


# Filtering Results

Each section inside the docs that supports filtering will have a list of supported filters defined and you can specify as a query parameter while making the request.

Filters should be provided as a part of the enpoint URL in the following format:


For example, lets say that you want to get all the customers that are named John. It can be done by providing the name filter while making the request:


There are two different types of filters, the exact and partial filters.

# Exact Filters

Exact filters will only return those records where a specific attribute is exactly the same as the provided filter value.

For example, if an endpoint supports an exact filter for filtering out the records by status and if you provide ?filter[status]=1 query parameter, only records that have the status attribute set to 1 will be returned.

# Partial Filters

The partial filters are usually used for text based fields an it will return all the records that have the provided filter vaule anywhere within the attribute value.

For example, if there is a filter name defined for the specific resource and you provide the ?filter[name]=one filter within the URL, the API will return all the customers from the db that contain the word one anywhere within their name attribute and not only those who has the name exactly set as one.

# Sorting Results

All sortable resources will provide the list of sortable fields that can be used for sorting the data that is being returned from the API.

To sort a resource by the specific field, just append the ?sort=FIELD query parameter while you make the request to the API endpoint and it will sort the items in ascending order. To sort the items in descending order, prefix the field with - sign: ?sort=-FIELD.

For example, if you want to sort the tickets in ascending order by the created_at timestamp, you should make a request to the following endpoint:


If you want to sort them by the created_at timestamp in descending order, the enpoint should be updated to look like the following:


Support Hub API provides a convinient way to fetch some related resources while fetching a specific resource. For example, it can be pretty useful to get the info about the user who created a specific ticket while fetching the ticket itself.

If there are some supported includes for the specific endpoint, they will be provided inside the endpoint description. To specify which additional resources you want to include, just append the include query parameter to the URL, like following:


For example, if you want to include the details about the user who created a ticket while fetching the ticket list, your query parameters will look like the following:


Each ticket in the list of tickets returned by the API will now have the additional user object where you can find all the info about the user who created the ticket.