Registro de cambios de la API

Cada cambio en TrackFlo Integration API, del más reciente al más antiguo.

10.16.26

• Nuevo campo opcional en POST /api/v1/loadlegs/upsert: no_contact_load. Envíe true cuando su TMS marque el movimiento (o su pedido) como no contactar. TrackFlo no enviará mensajes automatizados sobre él (SMS, voz, WhatsApp, correo electrónico al transportista, MacroPoint) y mostrará un icono de no contactar en el tablero.

• Nuevo campo opcional en POST /api/v1/stops/upsert: planned_appointment_utc, la cita planificada original de la parada, que se conserva como la primera fecha planificada incluso después de una reprogramación. Este campo habilita la excepción Planned ETA Drift. Para un plan que solo incluya una fecha, envíe las 12:00 en la hora local de la parada, expresadas en UTC.

• Nuevo campo opcional en POST /api/v1/loadupdates/upsert: eta_stop_permalink, la parada a la que corresponde eta_utc (su native_system_stop_permalink). Si no se incluye, TrackFlo asume que corresponde a la siguiente parada a la que aún no se ha llegado.

9.25.26

• Nuevo campo opcional en POST /api/v1/loads/upsert: commodity contiene la carga del pedido. El nivel superior contiene los totales del pedido: description, pieces, weight y weight_unit. Una lista opcional items proporciona las líneas que los componen, con las mismas cuatro claves en cada línea.

  • pieces y weight deben ser números JSON, no cadenas de texto.

  • weight_unit es obligatorio siempre que se envíe weight.

  • pieces cuenta únicamente las piezas. Una cantidad que su TMS registre en pallets u otras unidades de manipulación no es un recuento de piezas, por lo que debe omitirla.

  • 0 piezas es válido (carga a granel).

  • Se aceptan claves adicionales.

  • El objeto reemplaza lo que TrackFlo tiene almacenado; envíe null para borrarlo.

  • Un commodity con formato incorrecto hace que falle toda la operación de actualización o inserción con 400, y details indica el campo. Consulte Modelo de datos.

9.12.26

• Nuevo campo opcional en POST /api/v1/loadlegs/upsert: driving_type: single o team. Envíelo cuando su TMS lo sepa. Si se omite, TrackFlo conserva el valor que ya tiene, excepto cuando driver_2_name o driver_2_phone_number contienen un valor; en ese caso, la etapa pasa a ser team (nunca cambia automáticamente a single). Las etapas team se excluyen del cálculo de ETA del descanso para un solo conductor cuando una empresa lo habilita.

• La página de autenticación y la especificación ahora indican que una clave se emite para un solo tipo de cliente: una clave de integración permite acceder a las operaciones de actualización o inserción /api/v1/* y a ninguna otra; si allí se presenta una clave de otro tipo, se rechaza con 403.

9.9.26

• get-assignee acepta únicamente X-API-Key únicamente. El parámetro de consulta heredado token ya no se acepta; una solicitud sin el encabezado devuelve 401, independientemente de la cadena de consulta. Todos los espacios de trabajo de Front se migraron primero a una clave de Front Integration, por lo que no es necesario cambiar la configuración, a menos que la suya aún dependa de token=.

9.6.26

• Se documentaron los significados de las marcas de tiempo (_utc / _local; los desplazamientos no se convierten) y la política de versiones.

• Primera publicación de la referencia OpenAPI 3.1 para los cinco endpoints de actualización o inserción.

• Las respuestas de actualización o inserción ahora son un contenedor JSON {status, message, permalink} en los cinco endpoints (los códigos de estado no cambian).

• get-assignee acepta X-API-Key (claves de Front Integration); el parámetro de consulta heredado token se está retirando.

• Límites de solicitudes por clave con 429 + Retry-After.