1. Inferences
  2. Shipping Label Inference

Inferences

Shipping Label Inference

You can have the inference via the API or the vision-SDK while the vision-SDK will do the network request for you, the responses from this document will remain the same.

New Inference

POST
`/v1/inferences/images/shipping-labels`

To create a new inference for shipping-labels, you'll need to pass the image_url as a base64 encoded data URL or public web URL. There's a soft cap of about 7.5MB per image for the base64 URL.

You're also able to specify what type of image the parser is looking at, so it can better extract data accurately along with other helpful information listed below:

image_url string (required)
Base64 encoded data URL.

barcode_values Array.<String>
Any existing values you've already extracted from the barcode.

location_id String
The ID of the location you want to attribute to this scan.

layout_id String
The ID of the layout to attribute to this scan. The layout must be associated with the specified location_id.

child_shipments Array.<String>
An array of shipment IDs to attach as child shipments to the parent shipment created from this inference. This enables the parent-child shipment hierarchy where a parent shipment (e.g., a pallet or consolidated box) contains multiple child shipments. Can also be an object with add, remove, or set arrays for updating an existing inference. Only applies when the tracker type is "outbound". Child shipments must be at the same location and have a status of created, delivered, or return_to_sender.

options Object
Option contains different other optional parameters you can provide along with the image. Those parameters are described below

Show Details

match Object
All the options associated with matching contacts logic.
(These parameter are only required if you are using contact matching)

Show Details
location Boolean
This option will be utilized if you wish to match the extracted sender and recipient fields with existing contacts in your organization. The parameter is a boolean that specifies whether to conduct the matching within this specific location or across the entire organization. For inbound scans, the location filter applies only to recipient matching. For outbound scans, it applies only to sender matching.
search_score_threshold Number
The matching score refers to the degree of similarity between the contact being matched and the existing contacts. Scores range from 0 to 1, where 1 indicates a perfect match. By default, the score is set to 0.8.
search Array.<String>
It will be a list containing possible values of 'sender', 'recipient', or both. This specifies whether the matching process should target the recipient, the sender, or both fields.
multi_hop_order String
When inbound multi-hop rerouting is enabled at the organization or location level and the recipient is not found at the scan location, the system searches across all locations in the organization. This option controls how cross-location matches are ordered. "by_score" (default) ranks by similarity score. "by_location" prioritizes contacts whose location address matches the recipient's address. Possible values: "by_score", "by_location".

postprocess Object
Optional postprocessing parameters

Show Details
require_unique_hash Object
If this property is set to true, it compares package hashes to determine if a package is a duplicate. If the hashes match, the package will be marked as a duplicate. By default, this property is set to true.
parse_address Array.<String>
It will be a list containing possible values of 'sender', 'recipient', or both. This specifies whether the extracted sender and recipient addresses should undergo parsing by the address parser.
provider_selection String
This option determines which provider to use in case of multiple providers, can be use_first, use_last or select. Option select will leave the provider object empty/null in case of multiple providers and will result in error multiple_providers

tracker Object
This parameter is optional and serves to track the package. It is only required if you intend to create a tracker object. If you are using the OCR API only, you do not need to specify these parameters.

Show Details
create_automatically Boolean
Boolean specifying whether to create a tracker object automatically or not, it's default to false.
status String
Different status options available with tracker object. Possible options are provided here
use_existing_tracking_number String
To use the same tracking number for tracking of packages as printed on the label. Otherwise PackageX will assign a new tracking number for keeping track of it. It's defaults to true.
type String
The type parameter can take one of two values: "inbound" or "outbound." Use "inbound" if the package is being scanned at the destination location, and "outbound" if it is scanned at the source location.
parcel String
Controls parcel creation strategy when extending an existing tracker chain. "always_create" (default) always creates new parcels. "use_existing" reuses parcels from existing shipments in the chain. "use_existing_if_tracking_and_order_number_match" reuses parcels only when both tracking number and order number match an existing shipment.
create_destination_shipment Boolean
When true and the tracker type is "outbound", an inbound "expected" shipment is automatically created at the destination location. This enables end-to-end tracking where the destination receives visibility of incoming packages before they arrive. Defaults to false.
destination_shipment_location_id String
The ID of the location where the destination shipment should be created. Required when create_destination_shipment is true. Must be a valid location within your organization.

chained_status TrackingStatusOutstanding

options?.tracker?.chained_status

        enum TrackingStatusOutstanding {
  provider_at_pickup
  package_accepted
  out_for_delivery
  provider_at_dropoff
  scheduled
  driver_dispatched
  package_at_waypoint
  in_transit
  pickup_available
  recipient_at_pickup
  added_to_container
  removed_from_container
  added_to_vehicle
  removed_from_vehicle
  delivered_to_provider
}

      

auto_close_shipments_option TrackerCloseShipmentsOption

options?.tracker?.auto_close_shipments_option

This option determines how to handle outstanding shipments: on_provider_updates: Outstanding shipments will be closed only when the provider sends a tracking update to the shipment. on_all_updates: Outstanding shipments will be closed on any tracking update to the shipment. off: Outstanding shipments will be ignored.

Default: on_provider_updates

        enum TrackerCloseShipmentsOption {
  on_provider_updates
  on_all_updates
  off
}

      

auto_close_shipments_status TrackerCloseShipmentsStatus

options?.tracker?.auto_close_shipments_status

When on_all_updates or on_provider_updates is active, you can select the following completed non-exception statuses for outstanding shipments:

        enum TrackerCloseShipmentsStatus {
  delivered
  picked_up
}

      

js
        const data = {
  image_url: "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAASA...", //truncated
  barcode_values: [], //If you have already extracted any barcode values from a shipping label
  location_id: null, //You an optionally pass the location ID to later filter scans by location
  layout_id: null, //You can optionally pass the layout ID. The layout must be associated with the specified location_id
  child_shipments: ["ship_abc123", "ship_def456"], //Optional array of child shipment IDs to attach to the parent shipment (outbound only)
  options: {
    tracker: {
      status: "pickup_available",
      create_automatically: false,
      type: "inbound",
      parcel: "always_create",
      chained_status: "in_transit",
      auto_close_shipments_option: "on_all_updates",
      auto_close_shipments_status: "picked_up",
      create_destination_shipment: false,
      destination_shipment_location_id: null,
    },
    postprocess: {
      parse_addresses: ["sender", "recipient"],
    },
    match: {
      location: false,
      search: ["recipient"],
    },
  },
};

const res = await fetch("https://api.packagex.io/v1/inferences/images/shipping-labels", {
  method: "POST",
  headers: {
    "PX-API-KEY": process.env.PX_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify(data),
}).then((res) => res.json());

const scan = response.data;

      

Inbound Rerouting (Multi-Hop)

When inbound multi-hop rerouting is enabled at the organization or location level, the system can automatically detect when a package does not have a recipient match at the scanned location and attempt to find the correct recipient across all locations in the organization.

If a match is found at a different location, the inference response will include a destination_location object indicating where the package should be rerouted to.

If the system matches a recipient but cannot determine the destination location, the inference will include a destination_location_unknown error. You can resolve this by updating the inference with a destination_location_id:

js
        const data = {
  destination_location_id: "loc_..."  // Must be one of the matched recipient's associated locations
};

const res = await fetch("https://api.packagex.io/v1/inferences/images/shipping-labels/sli-id", {
  method: "POST",
  headers: {
    "PX-API-KEY": process.env.PX_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify(data),
}).then((res) => res.json());

const scan = res.data;
// scan.destination_location => { id: "loc_..." }
// scan.errors => [] (destination_location_unknown resolved)

      
INFO

Rerouting only applies to inbound scans and recipient matching. It will not trigger for outbound scans or sender matching. The feature must be enabled in your organization settings (settings.inferences.shipping_labels.inbound_multi_hop_enabled) and can be overridden per location.

Inference Exceptions

The Exceptions feature allows us to flag specific shipping label inferences that contain anomalies or irregularities detected during processing. When an inference is in exception state, it can not be transformed however it can be reviewd and resolved out of the exception state and then it can be transformed.

This capability is useful in scenarios where the OCR model successfully processes the label image but encounters issues that affect the quality or reliability of the extracted data. Examples include:

unknown_contact – Contact information cannot be reliably identified.

addressed_generically – The label is addressed to a generic title (e.g., "Customer" or "Resident").

damaged_label – The physical label appears partially destroyed or unreadable.

suspicious – The label contains patterns that may indicate fraud or tampering.

arrived_opened – The package is detected to have been opened prior to delivery.

We can update an existing inference record and set it to exception, along with appropriate exceptions type.

js
        const data = {
  exceptions: {
    unknown_contact: true,
    suspicious: true
  }
};

const res = await fetch("https://api.packagex.io/v1/inferences/images/shipping-labels/sli-id", {
  method: "POST",
  headers: {
    "PX-API-KEY": process.env.PX_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify(data),
}).then((res) => res.json());

const scan = response.data;