Reference · built on requestOperator by FibricOrders & fulfillment

Carrier Exception

Acts on each carrier exception scan, whether damaged, held, or misrouted, with a reroute, a reship, or a notice per shipment.

About

An exception scan means the carrier has stopped following the plan. This operator reads exception events as tracking services and carriers report them: an AfterShip tracking tagged Exception with its event code, a Shippo substatus such as package_damaged, package_lost, or address_issue, an EasyPost tracker status_detail, a FedEx delayDetail with its reason, or a ShipBob order.shipment.exception. It finds the order, the customer, the value of the goods, and whether the shipment is still moving.

For each shipment it proposes one action from your policy: a reroute where the carrier allows an intercept, a reship from stock, or a notice to the customer with the scan quoted. A person approves, and the shipment's record shows the scan, the action, and the outcome.

This is a reference listing. It documents what Fibric would read from Carrier Exception and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • AfterShip trackings tagged Exception, with checkpoint event codes such as held_by_customs, delayed, or returned_to_sender
  • Shippo tracking status FAILURE or RETURNED with substatus package_damaged, package_lost, address_issue, or return_to_sender
  • EasyPost tracker.updated events with the status_detail and the tracking_details scan history
  • FedEx scan events with delayDetail status DELAYED and its type and subtype, from the Track API
  • ShipBob order.shipment.exception and order.shipment.on_hold webhooks with their status_details
  • The order, its line items and value, and any open help desk ticket from the same customer

Proposed actions

  • Target capability: propose a UPS Delivery Intercept, return to sender or alternate address, when the carrier has misrouted the package
  • Target capability: propose a reship from stock as a new fulfillment with the original order referenced
  • Target capability: propose a customer notice on the help desk ticket quoting the exception scan and the next step
  • Target capability: propose a return label when a damaged package is to come back before the reship
  • Target capability: propose marking the AfterShip tracking completed once the replacement is delivered

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Reship the damaged package

    When Shippo reports package_damaged, propose the new Shopify fulfillment, the return label, and the Gorgias notice in one review.

    With Shippo, Shopify, Gorgias

  • Reroute the misrouted parcel

    When an AfterShip checkpoint shows the package heading to the wrong city, propose the UPS Delivery Intercept with the corrected address and its charge.

    With AfterShip, UPS

  • Tell the customer before the 3PL does

    When ShipBob raises order.shipment.exception, propose the Kustomer message with the reason and the date the shipment is expected to resume.

    With ShipBob, Kustomer

  • Attach the FedEx delay reason

    Quote the delayDetail type and subtype from the Track API in the proposed notice, so the customer hears weather, not silence.

    With FedEx, Zendesk

Requirements

  • A tracking source that reports exceptions: AfterShip, Shippo, EasyPost, or the FedEx Track API
  • A store connector for the order and a new fulfillment, such as Shopify
  • A help desk connector for the customer notice: Gorgias, Kustomer, or Zendesk
  • A policy mapping exception types to actions, and an order value above which a person must be consulted before a reship
Authentication
Reads and writes through the tracking, carrier, store, and help desk credentials already connected; it stores none of its own.

Limits

  • Carriers differ in what an exception code means; the operator shows the code as reported, not a translation
  • A reroute is possible only where the carrier offers an intercept and the package has not been delivered
  • Carrier claims for lost or damaged goods are not filed here; the record it leaves is the evidence you attach to a claim
  • A reship it proposes consumes stock; when none is available it proposes the notice and a refund path instead

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Carrier Exception ↗

Questions and answers

What does the reviewer approve?
One action per shipment: reroute, reship, or notice, each with the exception scan it answers, the cost it implies, and the customer message that goes with it. Where the policy is silent, it proposes nothing and asks.
What record does an exception leave?
A timeline entry on the order with the carrier, tracking number, exception code and time, the action taken, the approver, and the result scan when it arrives. Notices and return labels link to the same entry.
What will it never do unapproved?
File an intercept, create a fulfillment, buy a return label, message the customer, or issue a refund. It does not file carrier claims at all.
Ask about Carrier Exception

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.