Skip to main content
Los campos personalizados son datos que tu empresa define para todos sus activos: un código de inventario, un centro de costo, un área. Cada campo tiene una etiqueta (lo que se ve en la plataforma) y un nombre interno fijo, que es la clave que usa la API: Esta guía recorre el flujo típico de una integración que sincroniza activos con su propio sistema (un ERP o un sistema de mantenimiento) usando el código de inventario como llave. Todos los ejemplos usan un API token en $ATLAS_TOKEN.
Los campos los crea un administrador de tu empresa en Configuración › Campos de activos. Leer valores requiere el permiso access_tracking o access_fleet_assets; escribirlos, access_fleet_assets. Un API token tiene los permisos del rol de su dueño.

1. Listar las definiciones

  • name es la clave del valor en el activo. No cambia aunque cambie la etiqueta.
  • type define el formato del valor: text y select son texto (en un desplegable va el value de la opción, no su etiqueta), number es número, date es YYYY-MM-DD y boolean es true/false.
  • rules.unique (Valor único) garantiza que dos activos de la empresa no tengan el mismo valor. Compara sin distinguir mayúsculas, tildes ni espacios de los extremos: asm-001 y ASM-001 son el mismo valor. Solo un campo con Valor único sirve para identificar activos.
Por defecto se listan los campos activos; ?status=all incluye los archivados.

2. Leer los valores de los activos

Cada activo trae customFields con los valores de los campos activos, bajo su nombre interno. Un campo sin valor no aparece.

3. Buscar por un campo

customFields.<nombre interno>=<valor> filtra la lista por igualdad. Varios filtros se combinan con «y».
El texto se compara sin mayúsculas ni tildes; número, fecha, opción y booleano, exactos.

4. Leer y actualizar un activo por su código

Con idField, el segmento de la ruta deja de ser el id del activo y pasa a ser el valor buscado. idField acepta plate, name o el nombre interno de un campo con Valor único.
Para actualizar, usá PATCH: cambia solo lo que envíes. En customFields, las claves enviadas se escriben, null o "" borran el valor y las ausentes no se tocan.
La respuesta es el activo actualizado. Cada cambio queda en el Registro de actividades de la empresa, con el canal «llave API».
Preferí PATCH a PUT: el PUT reemplaza el activo completo y exige que queden todos los campos obligatorios; el PATCH solo falla si vacía uno.

5. Cargar en lote

POST /api/assets/batch/update actualiza hasta 100 activos por llamada. Cada entrada identifica un activo por id, o por idField + idValue, y trae en data el mismo cuerpo que el PATCH. No crea activos. Empezá con "dryRun": true: valida todas las filas sin guardar nada y devuelve el mismo resultado que tendría la carga real.
La respuesta es siempre 200 con un resultado por entrada, en el mismo orden (index), y un resumen:
Cómo leerlo:
  • Una fila que falla no detiene a las demás. Para reintentar, reenviá solo las filas que no salieron updated.
  • Las filas se procesan en orden: un valor único repetido dentro del mismo lote falla en la segunda fila que lo trae (en el ejemplo, la fila 1 choca con la fila 0).
  • Cuando el resultado te conforma, mandá el mismo lote sin dryRun (o con false). Cada fila actualizada queda en el Registro de actividades como una edición del activo.
  • La respuesta es 400 solo si la petición en sí es inválida: más de 100 entradas, ninguna, un id mal formado o una forma incorrecta. En ese caso no se procesa ninguna fila.

Errores

En las operaciones de un activo (PATCH, PUT, POST) y en el campo error de cada fila del lote, los errores de campos personalizados traen details para que tu integración sepa qué corregir: Ejemplo de un valor que no cumple una regla:
Una clave que no es un campo de tu empresa, o que es de un campo archivado, responde 400 con details.key: la API no descarta valores en silencio. El resto del contrato de errores está en Códigos de error.