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 products and the fetched data. Some data flow limiting is nevertheless subject to variation depending on the Crypto APIs 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 products, please visit our website.

Crypto APIs 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 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 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. The charging type of every endpoint can be found at the bottom of the page of the endpoints' example response attributes.

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. You can see the amount of credits charged for every single endpoint by navigating to our Documentation, opening the endpoint in question and scrolling to the bottom of the page.

There are two charge types: "Request" and "List", where the latter is only for endpoints that can list multiple results and have pagination applied.

  1. The "Request" type charges a specific amount of credits per a single request. For different endpoints this could be a different amount, but most often it is 500 credits per 1 request. (The charging type can be different for the different endpoints)
  2. The "List" type charges a certain amount of credits per a specific count of results. Depending on the specific List endpoint this could vary, e.g. a more complex "List" endpoint could charge "100 credits per every result in the response".

Enabled features

Another way we limit data flow are the features each subscription tier holds. Crypto APIs 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, 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": {
        "offset": 0,
        "limit": 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 limit: 50. This means that regardless of the value of the property total in the response, by default only 50 can be displayed at a time. The default value of the limit property is set to "50", but can vary or be modified depending on the specific List endpoint.

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