VRS Load Testing Considerations

When planning and executing load tests on CARO's APIs, consider these guidelines in order to produce comparable and meaningful results.

Handling authentication in high-volume requests

Making sure you are familiar with our authentication guide is important for normal operations of our connected services and particularly relevant in the context of load tests involving a high volume of requests.

Additionally, please be reminded that your client ID has a daily limit of 150 tokens you may generate in the absence of any further arrangements with us (see also our FAQ. Take this into consideration when executing load testing scripts that generate tokens on each execution.

We recommend that you implement dedicated logic in your load tests to check if a token is still valid and only generate a new one if it is expired at the start of your load test execution.

Errors and retries on generations and verifications of VPs

Should you encounter any non-200 class response codes on the generation or verification of Verifiable Presentations (VP), we recommend the following actions based on the response code:

• 100-199: Not to be expected. Please contact us if you encounter these response codes.
• 200-299: Success. No action required. Continue with test.
• 300-399: Not to be expected. Please contact us if you encounter these response codes.
• 400-499: Indicates a client error (e.g. invalid input or, in most cases, an expired token). Abort test on any of these errors.
  • Check if your Bearer token is still valid. If not, generate a new one.
  • Check if your input data (especially on the verification of a VP) is handled correctly. This often indicates that a previous generation failed and the error was not handled.
  • If you believe your token and data are valid, contact us.
• 500-599: Indicates an unexpected server error. Abort test on any of these errors. Contact us.

General considerations for generations and verifications of VPs

For comparable results across load tests, we also recommend to implement the following measures:

• Always generate new correlation UUIDs for each generation of a VP. Do not reuse UUIDs. Our APIs will not error on duplicate UUIDs, but this will lead to a skewed result as our database will handle load and creation of results differently.
• Follow the intended flow of the API:
  1. Create a generation request
  2. Wait for the generation to finish
  3. Check for any unexpected errors (see above)
  4. Create a verification request with the data from the generation
  5. Wait for the verification to finish
  6. Repeat