I am currently developing using the SDK and have encountered an issue with the “Too Many Requests” error.
Could you please explain under what conditions this error occurs?
I am concerned that this error might occur when many customers access the site.
Specifically, we are facing this problem in the following case study:
To determine whether there are any available team members for a specific date and time, we use the SDK’s getAvailabilities method for each member. However, when there are many members, we quickly encounter the “Too Many Requests” error.
To resolve this issue, we would like you to either create an endpoint that returns a list of available members for a specific date and time or relax the conditions for the “Too Many Requests” error.
Let me start by saying that the Sesami SDK rate limit is what we built intentionally. It does not happen when many customers access the site, but when one user makes a lot of requests and only that one user will be affected not the rest of the customers.
If I may ask, why would you need to check each team member since our SDK can return availability based on “any available” (Or not setting the team member) work for you, building the booking experience you have in mind? If not, please provide an example request so we can analyze it.
We also have other API endpoints, and based on your feedback, we will determine the best approach to recommend to you.
It does not happen when many customers access the site, but when one user makes a lot of requests and only that one user will be affected not the rest of the customers.
This confirmation is very helpful!
Thank you!
If I may ask, why would you need to check each team member since our SDK can return availability based on “any available” (Or not setting the team member) work for you, building the booking experience you have in mind?
What we want to achieve is to get a list of available instructors for a specific time slot.
Here’s what we are currently building:
A service called “Any Instructor” that includes all instructors (Team members)
Get available dates/times for the “Any Instructor” service (we can achieve this with the current SDK)
After selecting a booking date/time, determine which specific instructors (Team members) are available (this is where we get Too many requests)
Display the list of available instructors (Team members) for customers to choose from
Make a booking with the selected instructor (Team member)
Is there another way to get a list of available instructors for a specific time slot?
If there’s a better approach, I would greatly appreciate your guidance!
I’d also like to know specifically how frequently requests from a single user would trigger an error.
This information would help us predict when these errors might occur.
Hi Morimoto! Thank you for being so patient! Our dev team is evaluating the best solution for you, and we’ll have an update soon.
Let us know if there’s anything specific you’d like us to consider in the meantime
Since the rate limit can be adjusted based on different infrastructure and network considerations at any given time, we recommend not focusing on knowing the limit and trying to not max it out. Instead we suggest focusing on optimizing the algorithm.
Did you have a chance review and read this section of the documentation about the Rate Limit? Avoiding rate limit errors
In the document, you can build mechanisms to work well with the ratelimit:
Include code that catches errors. If you ignore these errors and keep trying to make requests, your app won’t recover gracefully.
Your code should stop making additional API requests until enough time has passed to retry. The clients should rely on the retry-after header (on a 429 response) to retry.
This means, you’d get retry-after when you hit the rate limit, this will help your code to have a delay strategy and fetch data sequentially. We built something like that in this Proof of Concept in our demo store, on the booking popup: Sesami SDK List View Booking Experience – Sesami Demo
However, I was unable to get this method to work correctly. I am using the SDK’s getAvailabilities function to request available reservation times. It seems that this function becomes undefined and does not return a response when a 429 error occurs. As a result, I couldn’t retrieve the retry-after value.
The relevant code is as follows.
I performed an operation check with this code, but it did not work as expected.
As shown, error handling is implemented using a try-catch.
let availabileDate;
let retry = true;
while (retry) {
try {
console.log({ judgmentDateData });
availabileDate = await judgmentDateData?.getAvailabilities();
console.log({ availabileDate });
if (availabileDate?.status == 429) throw availabileDate;
retry = false; // Exit loop if successful
} catch (error) {
console.error('Error on getAvailabilities', error);
if (error.response && error.response.status === 429) {
const retryAfter = error.response.headers['retry-after'];
const delay = retryAfter ? parseInt(retryAfter, 10) * 1000 : 5000; // Default to 5 seconds if no header
console.log(`429 Error: Retrying after ${delay / 1000} seconds.`);
document.querySelector('.waiting-message').textContent = `Waiting for retry in ${delay / 1000} seconds...`;
document.querySelector('.waiting-message').classList.remove('hidden');
await new Promise(resolve => setTimeout(resolve, delay));
} else {
throw error; // Re-throw if not a 429 error
}
}
}
I don’t think it’s necessary, but I’ll upload the entire code for reference, just in case.
@Mohammad_Dehghani
I hope this message finds you well.
I wanted to follow up regarding the code I sent previously.
If there has been any progress, we would greatly appreciate an update.
This issue is of considerable importance to us, and we are eager to understand when a resolution might be expected.
Could you kindly inform us of the current status at your earliest convenience?
Thank you very much for your attention to this matter.
I reviewed the situation and discussed it with the development team. A development plan is in place to improve the SDK to better suit your workflow. In the meantime, I have a few tips to help you enhance code functionality:
When you get an undefined value, it typically means the rate limit was reached due to excessive requests. This situation won’t occur for most users, as they generally won’t refresh the page frequently. To handle this, please add an if statement that prevents further actions if the value is undefined.
Although the SDK includes a caching mechanism, you can implement an additional simple cache system to avoid fetching availabilities in a short timeframe (depending on how often availabilities change).
Lastly, error handling for getAvailabilities will not work with a try-catch block. Instead, use the onError method in SesamiDayObject for proper error handling.
As our development team noted:
“If the server responds with an error or a retry-after value that is too high, it will throw an error. This can be handled using the onError method on the slot object. For more details, please refer to the documentation: Storefront SDK | Sesami developers”
@Mohammad_Dehghani
Thank you very much for your prompt response and for considering various measures to address the situation.
It seems that the improvements made to the SDK’s caching system have indeed reduced the frequency of 429 errors, and I appreciate your team’s efforts in this regard. Additionally, I am grateful for the guidance on error handling. Using the onError method has enabled us to successfully catch errors as they arise.
However, I have noticed that the callback function of onError only returns the time (presumably the date of the SesamiDayObject checked by getAvailabilities) and still does not include the retry-after value.
If I may suggest, would it be possible to modify the onError response of the SesamiDayObject to return a JSON format that includes the retry-after value? I believe this might be a solution that could potentially be implemented with relatively minimal effort.
Thank you again for your attention to this matter, and I look forward to any insights or possibilities for improvement.
I hope this message finds you well.
It has been some time since I made a request for improvements, and I was wondering if there has been any progress.
If possible, could you kindly share an estimated timeline for when the improvements might be implemented?
hi @ryuji.morimoto , sorry for late reply
Sir, the SDK is still under development, and unfortunately, I cannot provide a reliable estimate at this time.
I have already submitted a proposal for SDK improvement, which includes your specific situation.
Could you please let us know how the progress is going on this matter?
At present, we are only acquiring the necessary information. However, when we make consecutive reservations, we frequently encounter 429 errors, making the system impractical to use.
We would greatly appreciate it if you could look into this issue.
hi @masaaki_hamada
sorry for the delay
can i ask if your booking experience flow requires multi bookings at the same time for the same customer or multiple customers booking a service the same time?
For our reservation flow, we offer 1:1 yoga lessons. A single customer may make multiple bookings, and multiple customers can also book at the same time. Each time slot and instructor combination is unique.
Currently, when we try to make multiple bookings in a short period, we always encounter a 429 error. It seems there is some rate limit in place, because as soon as a single customer attempts a second reservation (even if it’s only around four total reservations), a 429 error occurs and the booking cannot be completed. This issue arises when one customer wants to book various times with different instructors in quick succession.
Hi @masaaki_hamada ,
Thank you for explaining the scenarios and sharing a screen-recording.
We are discussing this with our Technical leadership and will update you soon.
