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/... .
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 primary_contact 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 bill_to objeto.
  • El shipping_address Campo ha sido reemplazado por el sold_to 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 attachment_refs Objeto, que organiza adjuntos en internal , external , y source_pdf 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 bill_to_customer campo permite facturar a un cliente diferente (por ejemplo, el padre) en lugar del cliente principal en la factura.