EventBridge Scheduler CreateSchedule ClientToken idempotency duration

Question

Hi,
I am currently looking at the CreateSchedule API for the EventBridge Scheduler:
https://docs.aws.amazon.com/scheduler/latest/APIReference/API_CreateSchedule.html#API_CreateSchedule_RequestSyntax
I see that there is a ClientToken I can use in the request to make the API idempotent to retries.

How long is that ClientToken going to be idempotent for? Put another way, at what duration will using the same ClientToken cause the request to not be idempotent, in this case, create another schedule?

Thank you!

Anusha_R · Accepted Answer

We have completed our internal review regarding the clientToken field in the requests. While this field is present in the request structure, we can confirm that the idempotency feature is not yet implemented in the current version of the service.

Please be advised that our Cloudwatch development team has acknowledged this gap and is actively working on implementing full idempotency support. We will notify all users once this feature becomes available.

Thank you for your patience and understanding as we work to enhance our service reliability.

re:Post Agent · Answer

The CreateSchedule API for EventBridge Scheduler does provide a ClientToken parameter for ensuring idempotency, but the documentation does not explicitly state the duration for which this token remains valid. However, based on common practices in AWS services, we can infer some information about idempotency tokens:

1. Idempotency tokens are typically designed to prevent duplicate operations within a reasonable timeframe, often ranging from a few hours to 24 hours.

2. For example, in Amazon ECS, the time to live (TTL) for client tokens used in the RunTask API is 24 hours or the lifetime of the resource plus one hour, whichever is lower.

3. It's important to note that reusing the same client token for different requests is not recommended. Each unique request should use a new, unique client token.

4. The exact duration of idempotency for the EventBridge Scheduler CreateSchedule API's ClientToken is not specified in the available documentation. Without this explicit information, it's best to assume a conservative timeframe and not rely on the token being valid for extended periods.

5. As a best practice, you should generate a new ClientToken for each unique CreateSchedule request, even if you're retrying the same logical operation. This ensures that your requests are treated as intended and avoids any potential issues with expired tokens.

6. If you need to ensure idempotency over longer periods or for more complex scenarios, you may need to implement additional logic in your application to track and manage the state of your schedule creation requests.

Given the lack of specific information about the ClientToken duration for EventBridge Scheduler, it's advisable to contact AWS support for definitive guidance if your use case requires precise knowledge of the idempotency window.  
**Sources**  
[CreateSchedule - EventBridge Scheduler](https://docs.aws.amazon.com/scheduler/latest/APIReference/API_CreateSchedule.html)  
[REL04-BP04 Make mutating operations idempotent - AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/2025-02-25/framework/rel_prevent_interaction_failure_idempotent.html)  
[Ensuring idempotency - Amazon Elastic Container Service](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/ECS_Idempotency.html)

EventBridge Scheduler CreateSchedule ClientToken idempotency duration

Relevant content