Good evening,
We’ve been using the old version of Stuart and we are planning on moving on V2, but recently V1 is giving us a lot of problems and we would like to know if these will be ongoing on V2, in reference with the pickupAt:
We do not understand how the datetime format works. We’ve always used datetime format with no gmt (We work in Spain, that has GMT +2) and it has been working until recently. Depending if we use the test server (sandbox-api.stuart.com) or the real server (api.stuart.com) we get different responses. For instance if I make a petition for ASAP in the test server, the delivery is not started until 2 hours later, but if I make it on the real server, it makes it on time.
We’ve also encountered another problem with both servers, which is that when we get the scheduling slots for Barcelona for today (2018-05-16) it says that we can make orders until 11pm if the duration of the delivery is less than 15 min. For a delivery time of 5 minutes, the server returns an error of pickupAt can not schedule a pickup at this time. The maximum time that we are allowed to schedule is at 8:30 PM for a 5 minute delivery!
Continuing the previous problem, if we set a job for 8:30 PM (2018-05-16T20:30:00), we get in the response that the pickupAt is “pickupAt”: “2018-05-16T22:30:00+02:00”. Shouldn’t it be 2018-05-16T20:30:00+02:00? Why is it adding 2 hours to the pickup? I’ve also tried with 2018-05-16T20:30:00+02:00 but the response is exactly the same.
The pickup at parameter is working the same way in v1 and v2 if you respect the ISO 8601 format.
You can refer to the How should I format dates? topic in the FAQ section for more information.
To set a job for 8:30 PM in Spain you must use the following format “2018-05-17T20:30:00+02:00” as Spain is currently 2 hours ahead of UTC.
The issues you are having are caused by the fact you are not providing any time zone information.
If no UTC relation information is given with a time representation it is ambiguous when used in communicating across different time zones. Even within a single geographic time zone, it will be ambiguous if the region observes daylight saving time (as Spain do). We recommend you to indicate a time zone (zone designator) using the standard’s notation to clear any ambiguity.
Hi Paul,
I’ve put the gmt +2 (2018-05-16T20:30:00+02:00), but in V1 the response i get for the pickupAt is:
pickupAt: 2018-05-16T22:30:00+02:00.
Adding on, if I put no gmt, if the command is done before 8:30 PM, the command is programmed CORRECTLY (IT GETS ON TIME).For example:
Why is it adding 2 hours to the pickup? Should’nt it be pickupAt: 2018-05-16T20:30:00+02:00?
What I believe is happening is that when you check whether the job can be done or not you are checking the response pickup (WHICH IS ADDING 2 HOURS, HENCE IT IS ONLY ALLOWED UNTIL 8:30 / 9 PM). Once you’ve checked whether you can do the delivery, you then must IGNORE the gmt because if I do a job for a time previous to 9 PM, the delivery IS ON TIME (adding or not the gmt). This has been happening the past week, we’ve always been sending the same format for the pickupAt (we’ve been using Stuart API for over a year).
Thanks for your complete message and your example. I can successfully recreate your issue.
The problem is that you are requesting the Create a Job from Job Quote v1 endpoint with url parameters instead of sending the attributes in the request body (Content-Type:application/x-www-form-urlencoded).
I do that on my API, I send the curl with the parameters on the body, but it doesn’t work. I send you an example from your documentation because it is more visual. Here my code in vb.net:
Dim curl as string=“https://api.stuart.com/v1/jobs?jobQuoteId=480237&pickupAt=2018-05-17T21:00:00.000+02:00”
Dim request = TryCast(System.Net.WebRequest.Create(curl), System.Net.HttpWebRequest)
request.Method = “POST”
request.ContentType = “application/x-www-form-urlencoded”
request.Headers.Add(“authorization”, "Bearer " & Authentification)
request.Headers.Add(“Cache-Control”, “no-cache”)
I would like to emphasize that this has been occurring during the LAST WEEK, I’ve always send the parameters the same way. This is a big issue for us because you have told me that it works the same in V2, which worries me.
We are sorry about the problem currently occurring to you.
Have you tried passing the content in the http request body instead of in the url params? You can have a look here for more details on how to do it in VB (sorry we are not VB experts), and also here to have a look at the documentation of the legacy v1 job creation endpoint.
Hello m.tyc,
We tried also in the body and it still doesn’t work (pickupAt can not schedule a pickup at this time) for a delivery over 9PM. We still do not understand how this is happening, as we’ve been using this for OVER A YEAR. Any method we try, even in the test platform from the documentation, we always receive the same response for deliveries over 9PM. We’ve been trying to solve this for about a week, and our priority is to solve this now. Please, could you give us a concise answer of why this is happening (other than making us re-write our API) or a solution to this?
As you know you are not the only one using our API v1 and scheduling jobs, from what we see this is an isolated problem occuring to you.
I think the issue come from the fact that our servers time are not set to UTC (which was not the case before), for some reason, passing the datetime in the url parameters truncates the offset (+02:00) in your case. It was working before because the servers time was in your timezone. So even if the datetime sent by your system before was not correct, it was still working because you were in the same timezone as our servers.
Here you can find a working example of a v1 job creation using our public API documentation:
As you can see, the pickup_at information in the response ( “pickupAt”: “2018-05-18T20:30:00+02:00”) is matching the one I specified in the request above.
Please can you share with us the details of your last request where you got the error saying “pickupAt can not schedule a pickup at this time” ? Please not that the pickup at cannot be in the past, and must fall within our operating hours as explained here.
After looking at your job quotes and job history in sandbox, we found out that the job were created with the correct pickupAt value. The job you created using the job quote 480237 has a correct pickupAt value (see job id 93784), it’s correctly planned to be pickup at 20:30.
We have problems AFTER 9PM. We had one for 21:30 yesterday (in Bacelona) that did not work. We had to do it via admin panel (https://dashboard.stuart.com/log-in). We have problems AFTER 9 PM. Do you have a way of contact by phone? I think it would be easier for me to explain what the problem is.
We confirm that scheduled jobs works in Barcelona, for every time slot that is available in this zone (see https://stuart.api-docs.io/v2/jobs/get-scheduling-slots). Whenever you share with us some info, please can you indicate some traceability information allowing to verify it, eg: jobQuoteId, jobId? Thanks
This is our log for stuart errors. (Yesterday delivery 21:30 Barcelona)The client made 2 tries:
Try 1 :
Date: 2018-05-16 21:30:44.927
Request: h ttps://api.stuart.com/v1/jobs?jobQuoteId=14094686&pickupAt=2018-05-16T21:53:00+0000&destinationComment=Puerta y piso:bajos, interior
Error:{“errors”:[{“key”:“JOB_PICKUP_AT_INVALID”,“code”:422000,“message”:“pickupAt can not schedule a pickup at this time”},{“key”:“JOB_PICKUP_AT_INVALID”,“code”:422000,“message”:“pickupAt is not a valid pickup time”}],“code”:422}
Try 2:
Date: 2018-05-16 21:31:06.753
Request: h ttps://api.stuart.com/v1/jobs?jobQuoteId=14094691&pickupAt=2018-05-16T21:54:00+0000&destinationComment=Puerta y piso:bajos, interior
Error: {“errors”:[{“key”:“JOB_PICKUP_AT_INVALID”,“code”:422000,“message”:“pickupAt can not schedule a pickup at this time”},{“key”:“JOB_PICKUP_AT_INVALID”,“code”:422000,“message”:“pickupAt is not a valid pickup time”}],“code”:422}
We’ve tried during all day in test server for +02:00 GMT and it gave us the same response, in body and url parameters.
After looking at your http request log in our sandbox environment, I confirm the datetime our platform is receiving from yours are not formatted correctly. Here are the data we received today from you:
Job 93826: 2018-05-17T18:25:00.000 02:00
Job 93732: '2018-05-17T20:02:00 02:00'
As you can see, the format you are sending is not correct, you are missing a + between the time and the offset. You can see this faq that describes how dates should be formatted.
You should have sent us:
Job 93826: 2018-05-17T18:25:00.000+02:00
Job 93732: 2018-05-17T20:02:00.000+02:00
I suggest you to verify the data is sent within the http body (and not within the params), and also verify how you format you Date object into a String object before passing it into the body.
From previous email:
Request: h ttps://api.stuart.com/v1/jobs?jobQuoteId=14094691&pickupAt=2018-05-16T21:54:00+0000&destinationComment=Puerta y piso:bajos, interior
As you can see, we are sending the plus.
Why is it working then for hours previous to 9PM? We use the same petition for both.
By sandbox do you mean test server? Because we don’t have deliveries for 20:02 in production. Obviously we are doing tests with test environment with all kind of parameters (wrong and right) to see where the problem is coming from.
If you continue sending us the jobQuoteId and the pickupAt information in the query string, it won’t work. In query strings, the space character is encoded as a +, that’s why our API doesn’t receive it.
Hi Maximilien,
I don’t understand what do you mean by space characters encoding as +. In the previous post, we only send spaces in the destinationComment. If we were sending the query string incorrectly, shouldn’t it always fail? why is it only failing in ours after 9PM? We tried ALL of your recommendations (gmt +2, sending request in body and not url parameters, date format) and it still doesn’t work. You are ignoring the fact that deliveries before 9PM work and get on time. We need to know why before 9PM it does work. We’ve been working with Stuart for over a year and this errors have been very recent (past week).
Thank you.
Hey Jordi, as we told you before, the problem is not related to this, but to the fact that you are sending the timestamp in url params, with a + parameters inside (which is interpreted as a space character).
Jobs are failing after 9PM because you are actually creating jobs for 11PM, as you don’t send us the offset correctly.
I am not sure how we can be clearer on this issue, the solution for you is: send the jobQuoteId and pickupAt information in the http request body, as documented in our public api v1 documentation. => If you continue sending it in the query string it will continue to fail.
Hope this help you understand the issue and fix it on your side,
Maximilien
Hi Maximillien,
We’ve solved the problem. It wasn’t a problem of whether the parameters where send through the body or the url parameters. We tried what you told us (sending through the body) and it still didn’t work. We then thought of directly encoding the plus sign (instead of sending the plus sign in the body or url parameters, we send %2B) and now it works both if we send them throught the body or url parameters.
Thanks for your time.
