500 Internal Server Error on Webservice API (JSON output & Order Status update)

[Jay Chauhan]

Hello,
I am facing two main issues with the PrestaShop Webservice API while running PrestaShop in Docker container (local environment).
 

1. Authentication API with JSON format

• When I call the API with output_format=JSON, it returns 500 Internal Server Error.
• The same request works fine with XML format.
• Example request (API key hidden for security):
   

  Quote

  curl --location 'http://localhost:8080/api?output_format=JSON' \
  --header 'Authorization: Basic <API_KEY>'

   

• Response: 500 Internal Server Error
• Logs show no additional info (please guide where to check deeper logs if needed).
   

2. Updating Order Status

• My order flow is:
• Current status: Authorized
• I successfully updated to: Processing in Progress
• Next, when I try to update to: Shipped → I get 500 Internal Server Error.
• Same sequence works correctly when changing statuses inside the Back Office.
• API Request (simplified, key hidden):
   

  Quote

  curl -X PUT 'http://localhost:8080/api/orders/ORDER_ID' \
  -H 'Authorization: Basic <API_KEY>' \
  -H 'Content-Type: application/xml' \
  -d '<prestashop>...<current_state><![CDATA[4]]></current_state>...</prestashop>'

   

• Question: Is there a predefined sequence of allowed order status changes in the API?
• Or is this a bug with the Webservice, since the same transitions work in Back Office?
   

Steps to Reproduce

1. Run PrestaShop in Docker (local mode).
2. Create an order (status = Authorized).
3. Use API to change status → Processing in Progress (works).
4. Use API again to change status → Shipped (fails with 500).
5. Try API call with output_format=JSON → also fails with 500.

Environment

• PrestaShop Version: 9
• Running in: Docker image (local)
• Mode: Developer

Questions:

1. Why does the API fail with output_format=JSON while XML works?
2. Is there a required/predefined sequence of order status transitions when using the API (different from Back Office)?
    

Thank you in advance 🙏

Edited September 16 by Jay Chauhan (see edit history)

[Knowband Plugins]

On 9/16/2025 at 10:47 AM, Jay Chauhan said:

• Use API again to change status → Shipped (fails with 500).
•  

Are emails working? It might be an email issue as well. The system is configured to send the email in the Shipped status, but is failing to send the email due to mail settings. 

 

[Jay Chauhan]

Thank you for the suggestion but I don’t think this is related to email.

The reason is:

• Changing an order status to "Shipped" does work in some cases (for example, directly from "Authorized, To be captured by Merchant → Shipped").
• But if the current state is "Processing in Progress", and I then try to change it to "Shipped" via API, it fails with 500.

So the issue only happens depending on the previous status.
And this happens with some other statuses as well such as with "Delivered" → Shipped", which is obviously true, it should not happen but I don't know why it doesn't allow with others. My assumption is they have a predefined sequence of order status transitions.

My question is:
Is there a predefined sequence or workflow of allowed order status transitions in PrestaShop Webservice (different from the Back Office)?
If yes, where can I find documentation or configuration for this sequence?

Thanks again for your help!

[Jay Chauhan]

1 hour ago, Knowband Plugins said:

Are emails working? It might be an email issue as well. The system is configured to send the email in the Shipped status, but is failing to send the email due to mail settings. 

 

Thank you for the suggestion but I don’t think this is related to email.

Reason:

• Changing an order status to "Shipped" does work in some cases (for example, directly from "Authorized, To be captured by Merchant → Shipped").
• But if the current state is "Processing in Progress", and I then try to change it to "Shipped" via API, it fails with 500.

So the issue only happens depending on the previous status.
And this happens with some other statuses as well such as with "Delivered" → Shipped", which is obviously true, it should not happen but I don't know why it doesn't allow with others. My assumption is they have a predefined sequence of order status transitions.

My question is:
Is there a predefined sequence or workflow of allowed order status transitions in PrestaShop Webservice (different from the Back Office)?
If yes, where can I find documentation or configuration for this sequence?

Thanks again for your help!

[Knowband Plugins]

1 hour ago, Jay Chauhan said:

Is there a predefined sequence or workflow of allowed order status transitions in PrestaShop Webservice (different from the Back Office)?

No, there is no such predefined workflow. Status can be changed randomly. 

Anything in the Docker log, OR PrestaShop log file, OR in the debug mode?

[Jay Chauhan]

On 9/19/2025 at 6:53 PM, Knowband Plugins said:

No, there is no such predefined workflow. Status can be changed randomly. 

Anything in the Docker log, OR PrestaShop log file, OR in the debug mode?

Thank you for the suggestion.

I enabled debugging mode as you advised and found the root cause of the first error.
It was due to multi-store setup → the SQL was failing with a duplicate key error:
 

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '36-0-0-0' for key 'product_sqlstock'..

To fix this, I added id_shop in the query params, and the issue was solved.

However, when I try the same fix with the following API, it still fails with a fatal error:

Request:

curl --location 'http://localhost:8080/api?output_format=JSON&id_shop=1' \
--header 'Authorization: <API_KEY>'

Response:
 

Fatal error: Uncaught TypeError: array_filter(): Argument #1 ($array) must be of type array, string given
in /var/www/html/classes/webservice/WebserviceOutputJSON.php:168
Stack trace:
#0 /var/www/html/classes/webservice/WebserviceOutputJSON.php(168): array_filter('addresses')
#1 [internal function]: WebserviceOutputJSONCore->{closure:WebserviceOutputJSONCore::overrideContent():167}('addresses', 0)
#2 /var/www/html/classes/webservice/WebserviceOutputJSON.php(167): array_walk(Array, Object(Closure))
#3 /var/www/html/classes/webservice/WebserviceOutputBuilder.php(352): WebserviceOutputJSONCore->overrideContent('The Customer, B...')
#4 /var/www/html/classes/webservice/WebserviceRequest.php(1828): WebserviceOutputBuilderCore->getResourcesList(Array)
#5 /var/www/html/classes/webservice/WebserviceRequest.php(620): WebserviceRequestCore->returnOutput()
#6 /var/www/html/webservice/dispatcher.php(100): WebserviceRequestCore->fetch('•••••••', 'GET', '', Array, false, NULL)
#7 {main}
  thrown in /var/www/html/classes/webservice/WebserviceOutputJSON.php on line 168

So my follow-up question is:

• Why does the API still not work correctly with output_format=JSON after adding id_shop?
  With XML it works fine, but JSON crashes.

Is this a known bug in the Webservice JSON output, or am I missing some configuration for multi-store?

Thanks again for your help!

[Nickz]

On 9/16/2025 at 7:17 AM, Jay Chauhan said:

I am facing two main issues with the PrestaShop Webservice API while running PrestaShop in Docker container (local environment).

linux, freebsd, Windows (Version?) Or what rig you are using? 

[Jay Chauhan]

12 hours ago, Nickz said:

linux, freebsd, Windows (Version?) Or what rig you are using? 

Ubuntu 22.04.5 LTS

[Nickz]

9 hours ago, Jay Chauhan said:

Ubuntu 22.04.5 LTS

Does this help: 

https://stackoverflow.com/questions/69817102/array-push-argument-1-array-must-be-of-type-array-string-given

[Jay Chauhan]

17 hours ago, Nickz said:

Does this help: 

https://stackoverflow.com/questions/69817102/array-push-argument-1-array-must-be-of-type-array-string-given

Yes, but does it really solve my problem?

because I am using docker image to run Prestashop in local, I can resolve the problem by changing the file based upon the solution suggested by you but will this solve the problem in live system as well?
I am not sure whether this error persist in live system as well.

[Nickz]

On 9/23/2025 at 9:19 AM, Jay Chauhan said:

because I am using docker image to run Prestashop in local, I can resolve the problem by changing the file based upon the solution suggested by you but will this solve the problem in live system as well?

Copy the file rename it with _ or a 1 and edit the original. Without trying no one know if it works.  
If not just delete the edited file and rename the file1.php back to its original name.