Recommendations for migrating your account to credits-based pricing

Here are some important aspects of this new setup to consider:

info

Migration recommendations checklist

• Verify that you have implemented retry mechanisms in your code to properly handle 429 rate limit errors, should those arise.

• Capacity estimation: Review the credit cost table and perform needed estimations before migration to ensure you have an understand you will be on the right plan given your usage.

After migration:

• Key limits: Key request limits will not be ported over. These will need to be reconfigured in the context of credits usage.
• Optimizations: Review your usage a few days after the migration to understand how you have been using credits, and make the proper adjustments to make effective use of your plan and its limits.

Key Setting

With the migration to credits, all pre-existing key settings must be reviewed and properly reconfigured in the context of credits. ANY EXISTING key limits will not be ported, and you must reconfigure this with proper values under the new credit system.

important

There are important performance, cost and security implications to making this switch. We urge customers to start planning this out as soon as possible.

Sample migration scenario and guidelines

Under the credits-based model, a good default might be to use a multiplier between 50-100 of what you have now in order to convert to a good enough equivalent value in credits.

For example, let's say a key has a limit of 100k request per day. We multiply by, say, 80 credits to arrive at a new limit of 800k credits per day as the new limit.

You need to plan for this in advance, and once we have performed the migration, you will need to enable it.

Credit limits

As we migrate paid accounts from the previous request-based model to credits, depending on your usage, you might perceive the following:

• Faster or slower credit consumption
• Hitting limits while you still have available credits
  • This second case would be due to throughput limits. If this occurs, check how fast you are making requests; see below.

Retry mechanism

To handle rate limiting errors as part of this transition, we encourage developers to review their code and implement retry mechanisms to handle 429 errors properly. See the documentation on this topic for more.

Capacity planning

Review the documentation and the credit table for more details on the particular cost of each method in the context of your applications.

Migrating request packs to credit packs

We will be migrating any existing request packs to credits packs in a 1:1 fashion. The cost wil be the same, so you will not perceive an increase or decrease in your bill.