Crassula quotas and limits

This article lists the quotas and limits that apply to Crassula.

Overview

We impose quotas and limits on different requests in order to safeguard the system from an excess of data it cannot process and to maintain a fair allocation of system resources. We continuously monitor the needs of our customers and adjust our quotas and application algorithms accordingly to enhance security and prevent unauthorized use.

The number of registrations per hour

Quota on the number of registrations per hour from a single IP and the total number of registrations per hour:

• REG_QUOTA_IP=1

• REG_QUOTA_TOTAL=50

If the quota is exceeded, the API returns an error with code 429.

If the client uses their own front end and a custom IP address is used in the clientIp field during registration via API (/api/public/register), the quota will also be applied to the specified IP. Custom IP addresses can only be used with API keys.

SMS

Quotas for SMS messages are based on the client's verification status, phone number, and client ID:

Quotas based on IP addresses are not currently applied.

For verified clients:

• Number of messages per client/phone per hour: 50

• Number of messages per client/phone per day: 100

For unverified clients:

• Number of unconfirmed attempts from different IP countries and phone per day: 50

• Number of unconfirmed attempts to one country per day: 50

• Number of messages to a country per hour: 100

• Number of messages to a country per day: 800

• Number of messages per client/phone per hour: 10

• Number of messages per client/phone per day: 25

Cooldown periods for repeated unconfirmed attempts:

If a code from an SMS is not used (i.e., the user does not successfully confirm with the code), a cooldown is applied to each client/phone in case of repeated unconfirmed attempts within 24 hours:

• After the 1st attempt: cooldown of 1 minute

• After the 2nd attempt: cooldown of 10 minutes

• After the 3rd attempt: cooldown of 1 hour

• After the 4th attempt: cooldown of 8 hours

• Next attempt: available 24 hours after the previous one, and the attempt counter resets

Important notes on cooldown behavior

• Attempt counter reset:

  • The attempt counter resets in two cases:

    • Successful use of the code (i.e., the user successfully confirms with the code).

    • Exhaustion of the 24-hour period.

  • Successful code verification resets the cooldown counter immediately.

• Code invalidation upon new requests:

  • If a new code is requested during the cooldown period, the system will:

    • Generate a new code, invalidating the previous one.

    • Not send the new code due to the active cooldown.

  • Result: The user will not receive a new SMS, and the previous code they had becomes invalid.

  • Recommendation: Prevent users from requesting new codes during the cooldown period to avoid invalidating their existing valid code.

Interacting with SMS quotas in the Banking API:

The following API endpoints include headers indicating the time of the next allowed attempt, both in cases of success and when quotas are exceeded:

• POST /api/confirmation-codes

• POST /api/clients/{clientId}/tfa/confirmation-codes

• POST /api/clients/{clientId}/tfa/confirmation-codes-with-custom-phone

• POST /api/clients/{clientId}/phones

• POST /api/clients/{clientId}/phones/{id}/send

• POST /api/clients/{clientId}/phone-verification/request

Response Headers:

• 200 OK: Includes X-Next-Attempt-After header indicating when the next attempt can be made.

• 429 Too Many Requests: Includes X-Next-Attempt-After and Retry-After headers indicating when the next attempt can be made.

See Banking API for more detail.

Important behavior notes regarding code requests during cooldown:

• Cooldown check timing:

  • The cooldown check occurs at the time of sending the code, not at the time of code generation.

• Code generation during cooldown:

  • A new code is generated even if the request is made during the cooldown period.

  • This new code invalidates any previous code, but the new code is not sent due to the cooldown.

• Impact on users:

  • Users may receive a 200 OK response but will not receive a new SMS.

  • Their previously valid code becomes invalid, preventing them from completing the verification process.

• Recommendation:

  • Implement frontend checks to avoid sending code requests during the cooldown period.

When multiple clients share the same phone number for verification purposes, their actions can inadvertently affect each other's SMS quotas and cooldown periods. This note explains how the system manages shared phone numbers and provides guidance on avoiding potential issues that may arise from this setup. 

• Shared cooldown and Attempts:

  • If multiple clients share the same phone number, the cooldown and attempt counters are shared across those clients.

  • Reason: To prevent SMS pumping to a single phone number using different accounts.

• Impact:

  • Actions by one client can affect the cooldown status of another client sharing the same phone number.

• Recommendation:

  • Inform users of this behavior if they are likely to share phone numbers across multiple accounts.

  • Consider using unique phone numbers for each client to avoid unintended cooldown sharing.

Interacting with SMS quotas in the Web Interface:

The same quotas and rules apply in the Web Interface as on the backend. Additionally:

In the dialog window for entering the confirmation code from the SMS, if the quota is exceeded:

• The time until the next available attempt is displayed.

• The button for resending the code is hidden.

For clients implementing the cooldown functionality on their custom-made frontend, it’s essential to follow certain best practices to ensure a smooth user experience and prevent issues related to SMS quotas and cooldown periods:

• Prevent multiple rapid requests:

  • Disable the "Resend code" or "Login" button after it's clicked until a response is received or the cooldown period has elapsed.

  • Implement checks to prevent users from making multiple requests during the cooldown period.

• Utilize API response headers:

  • Use the X-Next-Attempt-After and Retry-After headers in API responses to inform users when they can make the next attempt.

  • Display the cooldown time to users, so they understand why they cannot request a new code immediately.

• Provide user feedback:

  • Show clear messages when users are in a cooldown period.

  • Explain the reason for any delays or restrictions to prevent confusion.

• Handle double-clicks and rapid actions:

  • Implement logic to handle accidental multiple clicks (e.g., double-clicking the login button) to avoid unintended code invalidation and cooldown extensions.

Other quotas and limits

Issued cards

To see the limit set for a particular card, navigate to Admin panel>Card Issuing>Issued cards, click the card from the list, and open the Limits tab.

For information on issued cards, see Card Issuing:

Transfers and transactions

For information on limits applied to transfers and transactions, see Limits.

eCommerce

Limits configured by the deposit_limits parameter:

• not_verified: 0

• email_verified: 250

• phone_verified: 1000

• identified: 15000

The default value is deposit_limits_default_amount: 1000.

Other eCommerce limits:

• client_limit_allowed_currencies: [ EUR ]

• client_limit_validity_period:

• - transaction: '180 days'

• - withdrawal: '30 days'

• client_limit_show_account_transaction_count: 5

The transaction_filter_default_limit parameter

For the /clients/{clientId}/transactions and /reports/transactions endpoints the parameter is configured as follows:

transaction_filter_default_limit: 100

Payall

The Payall functionality involves passing the limit value, which is either provided by the client or set as the default value:

client_default_monthly_limit: 1000000000

API error codes

Below are the API error codes that apply to limits in Crassula:

• 429

• 422