Data Flow Limiting

Data Limiting

Data limiting is much more helpful to the APIs operation and user’s experience than it sounds. The purpose of such strategies and processes is threefold - to prevent overloading of the API in one way or another, to ensure the best possible processing speed and response time, and to provide additional security to Crypto APIs 2.0 products and the fetched data. Some data flow limiting is nevertheless subject to variation depending on the Crypto APIs 2.0 product subscription tier you have as a customer. Different subscription plans provide different levels of data flow limiting. To see more details on Crypto APIs 2.0 products, please visit our website.

Crypto APIs 2.0 uses the following methods and strategies of limiting data flow:

Rate Limiting

API call Rate Limits are an essential part of Internet security designed to prevent DoS attacks, the overwhelming of an API, and the decreasing of its business value. What the process does is to basically limit the API calls sent simultaneously with your API key from a single source, as unlimited such could compromise both the performance and security of the API in question. API limiting also assists in boosting the API’s scalability which prevents lags during traffic spikes.

For these and more reasons Crypto APIs 2.0 professional service is subject to API call Rate Limits. All such limits, applied to you and your use, are based on your chosen subscription plan tier. If you are interested in increasing your Rate limits, you can always reach out to our team and set up a custom subscription.

In the case you exceed the aforementioned limits, your requests will return an HTTPS Status Code 429.

The Rate Limits are tracked and calculated on the basis of calls per day, per hour, per minute and per second in correspondence to available credits.

Daily credits

Crypto APIs 2.0 provides a specific amount of daily credits for the different subscription tiers of its product. The higher level the subscription, the more daily credits it provides. Your daily credits are accounted for 24 hours from the initial call made to our API-Gateway.

Daily credits allow you to actually make an API call. This is the limit of calls you can make for 24 hours. One credit doesn’t necessarily mean one request though. If you request a list of data, we count each 50 results (the pagination limit) as one credit.

Enabled features

Another way we limit data flow are the features each subscription tier holds. Crypto APIs 2.0 offers a variety of blockchain-related API products where each higher subscription tier provides more and better features for your preferences in retrieving blockchain and cryptocurrency data.

To see our prefixed subscription and pricing list with products, please see our website. If you feel like you can work better with a custom plan, simply contact our team and we’ll discuss the possibilities we can offer you.

Pagination

Using Pagination

When making calls to the Crypto APIs 2.0, a large number of results can be expected in the response. Blockchains consist of hundreds of thousands of data blocks at the least, containing hashed information on transactions which can add up to hundreds and more pages of information when called. To ensure the normal flow and structure of the results of the API response and optimize our efficiency, we paginate our results. Paginated results are returned usually to a GET request.

Example:

{
    "apiVersion": "2.0",
    "requestId": "xxxxxxxxxxxx",
    "data": {
        "limit": 0,
        "offset": 50,
        "total": 2,
        "items": [
            {
              //item 1
            },
            {
              //item 2
            }
        ]
    }
}

To avoid requests that may potentially crash the system or result in an error, we have set up a default limit on results with the value offset: 50. This means that regardless of the total number of items in the response, by default only 50 can be displayed at a time. This number cannot be modified to be more or less than 50.

To see how many items in total your request can return in general, see the value total. Depending on that number (if it is higher than the default offset: 50) and your preferences, you can send another request to fetch the next segment of the results again displayed within the default 50 items per page limit.

How do I know whether a certain endpoint uses pagination?

The process of pagination requires a request that would return a response of multiple items, or a list. When information is listed then It requires sorting and limiting of display.

Endpoints that request information on a specific item - address, transaction, block, etc., will return a single count of the requested item, along with its respected details, which are the goal of the request.

Example:

This is a response example for a request to GET address details. The value item being in the singular form, due to the request fetching information on one item, indicates there is no pagination for the specific endpoint.

{
    "apiVersion": "2.0",
    "requestId": "xxxxxxxxxxxx",
    "address": "xxxxxxxxxxxx",
    "data": {
        "limit": 0,
        "offset": 50,
        "total": 1,
        "item": [
            {
              //address details
            }
        ]
    }
}

Example:

The following is a different response example for a request to GET a list of addresses by a certain attribute. The value items is in the plural form, which indicates that the response includes more than one count of the requested information, which makes it a list. Ergo, this specific endpoint uses pagination.

{
    "apiVersion": "2.0",
    "requestId": "xxxxxxxxxxxx",
    "data": {
        "limit": 0,
        "offset": 50,
        "total": 1000,
        "items": [
            {
              //address 1
            },
            {
              //address 2
            },
    {
     …
    }
        ]
    }
}

How do I see the next page of the response?

Crypto APIs 2.0 obtains information from the blockchain database, therefore a new request has to be made in order to see further items from the response. The next response will still be limited to the default pagination value offset: 50, but you can get the next page by modifying the limit value.

limit indicates from which item in the list should the response start displaying results. The first paginated response of a request will by default start count from 0, i.e. limit: 0. By modifying this value you can retrieve the next segment of the results again displayed within the default 50 items per page limit.

Example:

{
    "apiVersion": "2.0",
    "requestId": "xxxxxxxxxxxx",
    "data": {
        "limit": 51,
        "offset": 50,
        "total": 1000,
        "items": [
            {
              //address 51
            },
            {
              //address 52
            },
    {
     …
    }
        ]
    }
}

To retrieve every segment of the response, in order to view all possible results, you have to each time make a new request with a modified limit. The default offset value cannot be modified to be more or less than 50.

Content


Social Sharing


Rate This Article