Migrando de 3.1 a 4.0

Información importante para actualizar desde 3.1 a 4.0 de la API.

Por favor asegúrate de haber migrado primero a 3.1 antes de migrar a 4.0 3.1 Guía de migración

Cambios Incompatibles

POST
{base_url}/api/v4/
  • Actualizar solicitudes a .../api/v4/... En lugar de .../api/v3.1/... .
Valores monetarios
  • El dinero ahora se envía y se devuelve como un número entero de centavos. En 3.1 los mismos campos tomaban dólares decimales, por lo que 45.99 en 3.1 se convierte en 4599 en 4.0.
  • Esto se aplica a los campos de dinero en general — totales de órdenes de compra, impuestos, descuentos, precios unitarios y totales de las líneas, montos de pago, asignaciones, precios unitarios de ítems y cualquier otro monto que envíes o recibas — no a un solo campo.
  • Este es un cambio silencioso: el mismo payload es aceptado en ambas versiones sin error, y significa una cantidad cien veces diferente. Es fácil equivocarse en ambas direcciones.
  • Enviar valores de 3.1 sin cambios a 4.0 cobra cien veces de menos: un 45.99 que significaba $45.99 se lee como centavos y solo cobra alrededor de $0.46.
  • Leer una respuesta de 4.0 como dólares cobra cien veces de más: un 4599 devuelto son $45.99 en centavos, pero leído como dólares se convierte en $4599.00.
  • Una excepción: el campo amount en el punto final de reembolso ya era un número entero de centavos en 3.1 y no ha cambiado en 4.0.
  • Afectando
    • POST
      {base_url}/api/v4/site/{site_id}/invoice/addUpdate
    • POST
      {base_url}/api/v4/site/{site_id}/payment/addUpdate
    • POST
      {base_url}/api/v4/site/{site_id}/item/addUpdate
POST
{base_url}/api/v4/site/{site_id}/customer/addUpdate
  • Campos de contacto de nivel raíz ( first_name , last_name , email , mobile_phone ) Debe proporcionarse ahora dentro de un primaryContact objeto, o como entradas en el contacts array.
  • El notification_options Campo ha sido eliminado. Las preferencias de notificación ahora se gestionan a nivel de contacto.
POST
{base_url}/api/v4/site/{site_id}/invoice/addUpdate
  • Los campos bill_email , bill_email_cc , bill_email_bcc , y billing_address han sido reemplazados por el billTo objeto.
  • El shipping_address Campo ha sido reemplazado por el soldTo objeto.
Productos → Artículos
  • El punto final de Productos ha sido renombrado a Artículos. Actualiza las solicitudes a site/{site_id}/item/addUpdate En lugar de site/{site_id}/product/addUpdate .
  • Afectando
    • POST
      {base_url}/api/v4/site/{site_id}/item/addUpdate
Archivos Adjuntos
  • El attachments El campo (una lista simple de URL) ha sido reemplazado por el attachmentRefs Objeto, que organiza adjuntos en internal , external , y sourcePdf sub-campos.
  • Afectando
    • POST
      {base_url}/api/v4/site/{site_id}/invoice/addUpdate
    • POST
      {base_url}/api/v4/site/{site_id}/customer/addUpdate
    • POST
      {base_url}/api/v4/site/{site_id}/subscription/addUpdate
Identificación de registro
  • Registros ahora son identificados y actualizados por _id En lugar de external_id .

Nuevo en 4.0

POST
{base_url}/api/v4/site/{site_id}/contact/addUpdate
  • Los contactos son ahora registros de primera clase. Utiliza los puntos finales de Contacto para crear, recuperar y gestionar contactos de forma independiente de los clientes.
POST
{base_url}/api/v4/site/{site_id}/invoice/addUpdate
  • Un nuevo billToCustomer campo permite facturar a un cliente diferente (por ejemplo, el padre) en lugar del cliente principal en la orden de compra.