Webservice de PrestaShop: PUT pone a 0 los campos que no envías

Si actualizas algo por el webservice de PrestaShop con PUT y mandas solo los campos que quieres cambiar, los demás se guardan a 0 o vacíos. Les pasó a dos compañeros en noviembre y diciembre de 2025. La respuesta corta: PUT sustituye el recurso entero. Lee el recurso, cambia lo que necesites y devuélvelo completo; o usa PATCH si tu versión lo admite.

Los dos casos

Primer caso. Un compañero quería cambiar un valor de configuración (PS_SHOP_ENABLE) y mandaba un XML con el id, el name y el value. El valor cambiaba, pero id_shop e id_shop_group pasaban a valer 0 en la base de datos. Probó a enviarlos vacíos con CDATA y seguía igual. Pensó en PATCH, pero creía que PrestaShop no lo admitía.

Segundo caso. Otro compañero montaba una integración: las consultas con su clave funcionaban, pero dar de alta productos o actualizar stock no. Revisando su código, en el grupo vieron tres cosas: usaba PATCH; metía el id entre dobles llaves dentro del CDATA ({{456}}), que no es un id válido; y la URL no llevaba https://. Otro miembro le pasó un ejemplo con PUT y alguien resumió el comportamiento: si envías PUT con parámetros sin valor, se guardan con valor 0.

Por qué pasa

Con PUT, PrestaShop carga el recurso, pero cada campo opcional que no viene en el XML lo deja vacío (null) antes de guardarlo; en un campo numérico eso acaba en 0. Si falta un campo obligatorio, devuelve un error 400. No es un fallo, es lo que significa PUT: «este es el recurso completo».

El flujo correcto: GET, cambiar, PUT

1. Pide el recurso con GET.
2. Cambia solo los campos que necesites.
3. Devuelve el XML completo con PUT.

$url  = 'https://mitienda.com/api/stock_availables/456';
$auth = 'Authorization: Basic ' . base64_encode($claveApi . ':');

// 1. Leer el recurso completo
$ch = curl_init($url);
curl_setopt_array($ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_HTTPHEADER => [$auth],
]);
$xml = simplexml_load_string(curl_exec($ch));

// 2. Cambiar solo lo necesario
$xml->stock_available->quantity = 25;

// 3. Devolverlo entero
$ch = curl_init($url);
curl_setopt_array($ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_CUSTOMREQUEST => 'PUT',
    CURLOPT_POSTFIELDS => $xml->asXML(),
    CURLOPT_HTTPHEADER => [$auth, 'Content-Type: application/xml'],
]);
$respuesta = curl_exec($ch);
$codigo = curl_getinfo($ch, CURLINFO_HTTP_CODE);

Comprueba siempre el código HTTP de la respuesta: un 200 indica que se guardó; cualquier otro trae en el cuerpo el motivo.

¿Y PATCH?

Depende de la versión. Desde PrestaShop 8.0 el webservice acepta PATCH y, en ese caso, solo actualiza los campos que mandas: es justo lo que buscaban los dos compañeros. En PrestaShop 1.7 no existe, y por eso la creencia de que «PrestaShop no admite PATCH» sigue circulando. Antes de usarlo, pruébalo contra tu tienda; si te devuelve error de método, vuelve al flujo GET + PUT.

Tres comprobaciones que ahorran tiempo

• Nada de llaves ni plantillas dentro del XML: el id va limpio, <id>456</id>.
• La URL completa con https, y la clave con permiso para ese recurso y ese método (consultar no es lo mismo que modificar).
• Pide el esquema en blanco (?schema=blank) para ver qué campos espera un recurso antes de crearlo.

La referencia oficial está en la documentación del webservice de PrestaShop. Si tu integración va a crecer, en PrestaShop 9 merece la pena mirar también la nueva Admin API.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación