Data Flow Limiting
Data Limiting
Data limiting serves three different purposes - it prevents any potential overloading events of the APIs in one way or another; it ensures the best available processing speed and response time on the performed requests; and it provides additional security to Crypto APIs products and the fetched data. Despite its name, the multi-layered functionality of data limiting significantly improves API operations and enhances user experience.
Data limiting varies based on the subscription tier of the Crypto APIs product you have as a customer. For detailed information on Crypto APIs products and the varying levels of data flow limitations across subscription plans, please visit [website] (https://cryptoapis.io/pricing).
Crypto APIs uses the following methods and strategies of limiting data flow:
Rate(Throughput) Limiting
API rate limiting sets limits on the number of credits that can be spent within a certain period of time along with relevant actions that can be taken. This allows ensuring the stability and performance of an API system. These limits are essential for internet security intended to - prevent DDoS and brute force attacks; prevent the overload of an API; and protect its business value from decreasing. The process essentially restricts simultaneous API calls sent with your API key from a single source, as unlimited calls could compromise both the performance and security of the API in question. Additionally, API limiting aids in enhancing the API's scalability, mitigating lags during traffic spikes.
For various reasons, the professional service provided by Crypto APIs is subject to API call Rate Limits. These limits, tailored to your usage, are determined by the subscription plan tier you choose. If you wish to increase your Rate limits, feel free to reach out to our team at [email protected] to set up a custom subscription.
Two different throughput limits associated with different credit per second limits exist:
Throughput Soft Limit (6,000 credits/sec) is the recommended threshold for data processing or transfer. Usage within this limit is billed at the base rate per credit. Throughput Hard Limit (12,000 credits/second) represents the maximum allowed throughput. Usage that exceeds the Throughput Soft Limit but remains within the Throughput Hard Limit will be billed at a rate slightly higher than the base rate. Exceeding the Throughput Hard Limit will result in a service interruption. Cost Penalty for Exceeding the Soft Limit Cost penalty is applied when the Throughput Soft Limit is exceeded but data processing and credit consumption limits remain within the Throughput Hard Limit. The cost penalty is calculated through a Cost Multiplier based on your active subscription plan.
Example within Throughput Soft Limit (6,000 credits/second): If 100 credits per second are consumed, this usage falls within the 6,000 credits per second soft limit. Therefore, clients are charged the base rate for each of the 100 credits, which costs a total cost of 100 credits.
Example within Throughput Hard Limit (12,000 credits/ second): In a scenario in which 8,000 credits per second are used, the usage is within Throughput Hard Limit, but it is exceeding the Throughput Soft Limit. Therefore, each of the credits consumed will be multiplied by the x1.3 cost penalty multiplier. Thus, 8,000 x 1.3 = 10,400 total credit cost.
| Subscription Plan | Soft/Hard Throughput limit | Credits cost increase |
|---|---|---|
| Free | 500/500 | 1.0 |
| Starter | 3000/6000 | 1.4 |
| Scale | 6000/12000 | 1.3 |
| Pro | 12000/24000 | 1.2 |
In case you exceed the aforementioned limits, your requests will return an HTTPS Status Code 429.
Monthly credits
Monthly credits is the total limit of credits included in the subscription plan which users can spend for different API calls, monitoring and operational activities. The monthly credit limit represents the credits accessible to a user.
Please be aware that you are allowed to purchase additional credits if you reach your credit limit. Monthly credit limit is not equal to the total number of credits that can be used. We have implemented this mechanism to assist you in advancing your projects and to remove any barriers that may be delaying or stopping the progress of your business - refer to Pay as you Go section for more information.
The chosen subscription tier of Crypto APIs products determines the amount of monthly credits allocated to a client, corresponding to their selected plan. Selecting higher-tier subscription plans provides clients with more credits which come at better rates.
Note that one credit does not correspond with the execution of a single request. Credit charges vary for every endpoint with pricing information made readily available at the bottom of the page with endpoints' example response attributes. For further information on credit charges for each single endpoint, please, navigate to our Documentation, opening the endpoint of your concern 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.
- 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)
- 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".
Pay As You Go
Crypto APIs employs a fair and transparent pricing model, enabling customers to pay solely for the services they use. This model is applicable across all paid subscription plans, meaning that users must be on any of the available paid plans of their choice prior taking advantage of pay as you go.
The primary aim of pay-as-you-go is to eliminate any potential barriers present in subscription plans that could hinder our clients' business. Rather than being strictly limited to predetermined credit amounts in subscription plans, we enable clients to continue using the services they need without limitations.
Once users reach and surpass the daily credits specified in their chosen subscription plan, they will automatically continue to use Crypto APIs services as part of our pay-as-you-go scheme. When exceeding the credits of their subscription plans, users will be required to cover the cost for all additional credits for executing all extra API calls that they made. The pricing for pay-as-you-go credits is determined by the active subscription plan chosen by the customer.
As part of the pay-as-you-go model, we introduced different automatic withdrawal limits which correspond with the user`s usage. These limits are triggered when specific levels (levels = additional value of services on top of the subscription plan) are reached. For example, when reaching an X amount of additional credits, the automatic withdrawal rule will be enforced for the first time and customers will be automatically charged with the corresponding payable amount. If users continue to use our services beyond that point, the next value limit will be reached soon which will trigger the automatic funds withdrawal mechanism for a second time.
To get information on the extra value/credit tiers and their thresholds, please navigate contact us at [email protected].
Charging structure
The pricing structure should offer clarity on how the credit-based model operates within the Crypto APIs suite. Most of the activities have a more simple structure and are easier to understand. However, some of the APIs work in a more specific way as each of these APIs is divided into a set of activities. Each of the activities is incurring a specific credit cost and has a different weight in the overall pricing.
Synchronizing an xPub enables the synchronization of all historical transactions and addresses within an Hierarchical Deterministic (HD) wallet, providing access to data as needed. There are four primary activities associated with xPub synchronization, each incurring different costs:
- xPub synchronization: Initiate synchronization through the Crypto APIs API.
- xPub monitoring: Daily monitoring of the entire xPub.
- Transaction operations: Handling addresses and transactions.
- Webhooks: Receive notifications (upon completion of the initial synchronization).
The address synchronization API functions similarly, with nearly identical actions permitted. It enables downloading and verifying historical transaction data associated with the synchronized address. It's important to note that while you can access data from the past 14 days without synchronization. Synchronization is necessary for retrieving older data. The actions that are allowed through the address API are:
- Address synchronization: Initiate synchronization through the Crypto APIs API.
- Address monitoring: Daily monitoring of the entire xPub.
- Transaction operations: Handling of transactions associated with the synced address.
- Webhooks: Receive notifications (upon completion of the initial synchronization).
With this specific API, clients can retrieve data from the past 14 days without requiring synchronization.
When it comes to webhook live events, clients can monitor on-chain activities for specific events such as new block creation, new transactions, token transfers, internal transactions, and beyond. The webhook live events API facilitates the execution of three key activities:
- Event Creation: Creating and subscribing to a particular event of interest for the client.
- Operations: Handling activities associated with the specific blockchain event.
- Daily monitoring: Daily monitoring of the active event.
- Webhooks: Receiving callback notifications.