Server error (500) when trying to create a job


I’m trying to create a job from a Python app and I’m getting a 500 but the same request in Postman is working. The URL I’m using is and he payload is:

    "job": {
        "pickups": [
                "address": "32 Coombe Ln, Raynes Park, London SW20 0LA",
                "comment": "Ask Bobby",
                "contact": {
                    "firstname": "ALI",
                    "lastname": "Brown",
                    "phone": "+33610101010",
                    "email": "",
                    "company": "Pizza Shop"
        "dropoffs": [
                "package_type": "medium",
                "package_description": "yellow package",
                "address": "23 Ethelbert Rd, London SW20 8QD",
                "comment": "3nd floor on the right",
                "end_customer_time_window_start": "2023-12-12T11:00:00.000+02:00",
                "end_customer_time_window_end": "2023-12-12T13:00:00.000+02:00"

Can you please shed some light into about the issue?


Hello @foobar,

Thank you for reaching out. We are currently reviewing the issue that you reported.
As soon as possible, we will share the feedback with you.

Best regards,

hello @foobar,

After reviewing your case we have found out that you submitted just part of your job from the Python app, the following JSON I am able to see in our logs from your side with this server error (500):

  "job": "dropoffs"

Please make sure you put the entire job when you submit from your Python app.
Let me know in case you face another such example.

Hi @Magdalena,

Thank you very much for the quick response. It was actually a mistake on my end as I was using the aiohttp library and using the data arg instead of json.

I’m facing a similar issue with the cancel order endpoint. Basically I am:

  • Creating an order (in postman) OK
  • Getting the order details to confirm status is “searching” (in postman) OK
  • Cancel job via Python app and I’m getting a 500 ERROR
  • Getting the order details again and the status has been updated to “cancelled” (in postman) OK

I am a bit confused by the fact that the call is returning an error but it seems to be working as the status gets updated? Any help would be very much appreciated.


Hi @foobar

I have reviewed the cancellation requests from your side and I confirm that you have successfully canceled the Jobs - where you received 204 No Content - this number code reflects a successful response.

At that stage, I can not find any logs which we are getting “500 error” from your side.

All looks good for now on your Sandbox account with canceling the Jobs.

Hi @Magdalena,

Thank you again for your quick and helpful response. Apparently the issue happened when I was trying to decode the response into json, but aiohttp was failing to do so because there’s no content-type: application/json header in the response. Is there any reason for that?



We do return the content-type: application/json` in the headers, you can test it via our Postman collection if you want to make sure.


Hi @Harold,

Thanks for the response. This is the list of headers that I get back when calling the cancel job endpoint using cURL (same as in Postman):

< date: Thu, 12 Oct 2023 17:29:04 GMT
< status: 204 No Content
< vary: Origin
< stuart-stack: V3
< x-request-id: 44abe15e-0bf1-4fd3-b069-783513748f21
< x-minuteratelimit-limit: 1000
< x-minuteratelimit-remaining: 999
< x-dailyratelimit-identifier: ratelimit:
< x-frame-options: SAMEORIGIN
< cache-control: no-cache
< x-dailyratelimit-limit: 500000
< referrer-policy: strict-origin-when-cross-origin
< x-permitted-cross-domain-policies: none
< x-xss-protection: 1; mode=block
< x-minuteratelimit-identifier: ratelimit:
< x-dailyratelimit-remaining: 499996
< x-download-options: noopen
< x-runtime: 0.683425
< x-content-type-options: nosniff
< x-powered-by: Phusion Passenger(R) 6.0.16
< server: nginx/1.20.2 + Phusion Passenger(R) 6.0.16

Please note that I do get the Content-Type header back in the response when calling other endpoints.



Sorry I didn’t get that you were talking about the cancellation endpoint.
For this one, that’s totally normal, as the response does not contain any json, because of the 204 No Content response code.
You can find the list of headers in our documentation if you have a doubt.