API Retry Logic

Many APIs do not fail immediately when they receive an error response. They retry the request a few times before giving up or succeeding. As a QA engineer or SDET, validating this behavior is often part of regression and resilience testing.

A common scenario looks like this:

• First request returns HTTP 400
• Second request returns HTTP 400
• Third request returns HTTP 200

The application should retry twice and succeed on the third attempt.

At first glance, this looks straightforward. The traditionally way is to build custom test services, modify backend code, or maintain dedicated environments to simulate sequential failures and recoveries. Such setup is often difficult to maintain and rarely provide consistent behavior across test runs.

With virtual sandboxing, you can model these scenarios directly using virtual APIs. Beeceptor lets you create stateful API behavior, making it easy to simulate predictable response sequences such as 400 → 400 → 200 without writing custom services or managing additional infrastructure.

The Setup

Start by creating a counter called retryCounter and initialize it to 0.

Next, create two mock rules for the same endpoint.

Rule #1: Simulate Failures

This rule matches when retryCounter is less than 2, which means the request is either the first or second attempt. It returns an HTTP 400 error and increments the counter so the next request advances to the next retry stage.

Return:

• HTTP Status: 400
• Checks for state condition retryCounter < 2.
• Error response payload

After sending the response, increment the counter:

{{step-counter "inc" "retryCounter" 1}}

This rule handles the first and second requests.

Rule #2: Simulate Success

This rule matches when retryCounter is 2 or greater, which corresponds to the third attempt. It returns an HTTP 200 success response and resets the counter, allowing the entire retry sequence to start over automatically for the next test run. Configure a second rule to match when .

Return:

• HTTP Status: 200
• Checks for state condition retryCounter >= 2
• Success response payload

After sending the response, reset the counter:

{{step-counter "reset" "retryCounter"}}

The endpoint now behaves predictably:

Request #1 → 400
Request #2 → 400
Request #3 → 200

After the success response, the counter resets automatically and the next test run starts from the beginning:

400 → 400 → 200
400 → 400 → 200
400 → 400 → 200

No manual cleanup is required between executions.

What Works

State-based mocking gives you deterministic behavior. Every test run receives the same sequence of responses, which is critical for automated testing.

You also avoid maintaining custom test servers, scheduled reset jobs, or scripts that manipulate test data between runs.

Since the logic lives entirely in mock rules, the setup remains easy to understand and update as retry requirements change.

More Scenarios

The same pattern you can use to simulate many real-world API behaviors:

• A payment gateway that fails twice before accepting a transaction.
• An inventory service that reports "out of stock" before inventory becomes available.
• A long-running job API that returns PROCESSING several times before returning COMPLETED.
• A webhook endpoint that intentionally fails the first few delivery attempts.
• Circuit breaker and fallback testing.
• Exponential backoff validation.
• Polling workflows where status changes over time.
• Third-party APIs with intermittent failures.

Instead of building specialized test services for each scenario, you can model these behaviors directly in Beeceptor using counters, state variables, and mock rules.

For quality assurance teams that regularly test resilience, retries, and failure recovery paths, stateful mocking provides a simple and repeatable way to validate behavior before production.