Actualizar datos de una empresa

PUT 
/company/:id

Un usuario solo puede actualizar su propia empresa. active se ignora si se envía; uuid nunca se modifica, y issuance_provider y has_agreement se ignoran siempre (los gestiona MATICERTS). Actualiza los datos de la empresa indicada. Los campos se envían como un objeto JSON serializado en records; solo se guardan los campos que cambian y que pertenecen a la lista de campos editables. El cambio se detecta con una comparación no estricta: dos textos numéricos se comparan como números (p. ej. 055010 y 55010, o +3001234567 y 3001234567, se consideran iguales) y null equivale a un texto vacío. Nota: en esos casos el campo no se guarda aunque la respuesta sea 200 con Registro actualizado correctamente.; compruebe el valor devuelto en dataRecords. El dígito de verificación (dv) solo se recalcula a partir de dni cuando records incluye country_id con el número 45 (Colombia; no el texto "45"): en ese caso dni es obligatorio (si falta, responde 500) y debe contener solo dígitos (con puntos o guiones el dv calculado es incorrecto). En otro caso se conserva el dv actual, así que si cambia el dni de una empresa colombiana envíe también country_id: 45. El logo se envía en base64 (imgdata + imgname) y se guarda en image. Correo: si records.email es un texto distinto del guardado (se comparan sin espacios al inicio ni al final), debe poder recibir mensajes (sin tildes, eñes ni espacios intermedios antes de la @ y con dominio válido); si no, responde 422 y no se guarda nada. Si records.email no es texto ni null (número, booleano, arreglo u objeto) también responde 422 con el mismo mensaje, aunque no se esté cambiando el correo. Un email igual al actual no se valida, así que una empresa con un correo antiguo inválido puede seguir editando el resto de campos. Un email vacío, solo con espacios o null responde 422 (El correo electrónico es obligatorio: no se puede dejar vacío.) si la empresa ya tiene un correo: el correo de contacto no se puede borrar; si la empresa no tiene correo, se acepta y sigue sin correo. Para no modificar el correo, omita email en records. El correo se guarda sin espacios al inicio ni al final. No se bloquea por empresa inactiva: los usuarios de una empresa deshabilitada pueden editar sus datos, pero no reactivarla. Solo se admite PUT (no PATCH).

Request

Responses

200

Empresa actualizada

400

La base de datos rechazó el cambio y la empresa no se actualiza. dni ya registrado en otra empresa: Ya existe un registro con ese valor (dato duplicado).. country_id, city_id, identity_document_id o type_organization_id que no existe (incluido null en cualquiera de esos cuatro campos): No se puede completar: un dato relacionado no existe.. Campo city_name enviado: No se pudo completar la operación en la base de datos.. El mensaje nunca incluye el SQL.

401

No autenticado

404

La empresa no existe, o no es la del usuario (el administrador accede a todas). Un {id} no numérico también responde 404 (la ruta no existe), con el cuerpo genérico de Laravel.

422

No se guarda nada. (1) records.email cambia a un correo que no puede recibir mensajes, o no es texto ni null (número, booleano, arreglo u objeto): message y errors.email traen el texto del ejemplo. (2) records.email vacío, solo espacios o null y la empresa ya tiene correo: El correo electrónico es obligatorio: no se puede dejar vacío. En ambos casos errors.email trae el mismo texto que message.

429

Límite general de 60 peticiones por minuto excedido. La cabecera Retry-After indica los segundos de espera.

500

records ausente, vacío o que no se puede interpretar (JSON inválido o un valor vacío o falso: [], null, 0, false, "" o "0"): mensaje "Error interno del servidor. La propiedad RECORDS no está definida.". También responde 500 si country_id es 45 y falta dni (message empieza por Error interno del servidor.) y ante otros errores internos. Un error de base de datos distinto de los de la respuesta 400 responde con un texto seguro (p. ej. "No se pudo completar la operación en la base de datos."), nunca con el SQL. Nota: si records no es un texto con un objeto JSON (se envía como objeto, arreglo, número o booleano nativo, o es un texto con un arreglo no vacío o un valor simple no vacío, p. ej. 1, true o "abc"), si imgdata no es texto, si imgname es un objeto JSON y imgdata trae contenido, si un campo de texto de records (p. ej. company_name) trae un objeto JSON, o si un usuario que no es administrador sufre un error de base de datos al comprobar su pertenencia a la empresa (antes de leerla), el cuerpo es el genérico {"message": "Server Error"}, sin success (o una página HTML si no se envía Accept: application/json).