Order Moves GraphQL

Order move GraphQL exposes moves, nested legs, organization-defined move and leg statuses, and their mutations.

The top-level orderMoves(..., search: String) quick search matches the move name and identifiers on its owning order. A term can match the order's trackingNumber or any value in the order's customValues map, such as a container number. Matching is case-insensitive and supports partial text.

Orders also expose getOrderMoves(filter, orderBy) and getOrderMove(filter, orderBy) for the moves that have not been worked yet. Both resolvers include moves with no status or a status in the Pending stage, and exclude moves in later stages. The plural resolver defaults to sequence order; the singular resolver returns the first matching move.

query {
  orders(organizationId: 1, filter: "orderId:9001") {
    items {
      getOrderMoves(orderBy: "sequence") {
        orderMoveId sequence name
      }
      getOrderMove(filter: "name:*pickup*") {
        orderMoveId sequence name
      }
    }
  }
}

query {
  orderMoves(organizationId: 1, search: "CONT-123", orderBy: "sequence") {
    items {
      orderMoveId sequence name startDate endDate
      assignedDriverContact { contactId name }
      orderMoveStatus { statusName statusStage color }
      dispatchRouteStops {
        dispatchRouteStopId dispatchRouteId plannedSequence
        stopType actualArrivalTime actualCompletionTime
      }
      orderMoveLegs {
        orderMoveLegId sequence name startDate endDate
        orderMoveLegStatus { statusName statusStage color }
        getAddress(idPropertyName: "contactAddressId") {
          contactAddressId name address1 city state postalCode countryCode
        }
        trackingEvents { eventDate eventDefinition { name } }
      }
    }
  }
}

Each leg exposes getAddress(idPropertyName: String!) for resolving a contact-address ID stored in its customValues. The resolver returns null when the property is absent or not an integer, and only returns an address belonging to the parent move's organization. The argument is the custom-value property name, not the address ID itself.

dispatchRouteStops is the inverse navigation for stops whose orderMoveId points to the move. It may contain stops from multiple routes and is ordered by dispatchRouteId, then plannedSequence. Expand it when a move query needs execution details; the collection supports GraphQL filtering.

Create and update values use a nested orderMoveLegs array. Update is sparse for scalar fields; supplied legs are reconciled by ID and array order.

mutation {
  createOrderMove(input: {
    organizationId: 1
    values: {
      orderId: 9001
      name: "Container move 1"
      assignedDriverContactId: 42
      orderMoveStatusId: 10
      orderMoveLegs: [
        { name: "Pick up", orderMoveLegStatusId: 20 }
        { name: "Deliver", orderMoveLegStatusId: 20 }
      ]
    }
  }) {
    orderMove { orderMoveId sequence orderMoveLegs { orderMoveLegId sequence } }
  }
}

Individual legs can also be managed without resending the parent move or its sibling legs. createOrderMoveLeg accepts orderMoveId and optional sequence, name, orderMoveLegStatusId, dates, and customValues; omitting sequence appends after the last active leg. updateOrderMoveLeg applies a sparse values map, while deleteOrderMoveLeg soft-deletes the leg. All three operations are scoped through the parent move's organizationId.

mutation {
  createOrderMoveLeg(input: {
    organizationId: 1
    values: { orderMoveId: 501, name: "Final delivery" }
  }) {
    orderMoveLeg { orderMoveLegId sequence name }
  }
}

Status dictionaries use createOrderMoveStatus, updateOrderMoveStatus, and deleteOrderMoveStatus, with equivalent OrderMoveLegStatus mutations. A status that is in use cannot be deleted.