Reference · built on requestOperator by FibricOrders & fulfillment

Cancellation Window

Reads each cancellation request against the order's pick, pack, and label state, then proposes cancel-and-refund, a void, or a return.

Request accessPricing ↗

About

Whether a cancellation is cheap depends on how far the order has travelled through the warehouse. Cancellation Window reads the request from your help desk and then the order's state: whether it is allocated, picked, packed, labelled, or already scanned by the carrier.

It proposes the path that state allows: cancel and refund in full when nothing has moved, void the label and refund when one exists but the carrier has not scanned it, an intercept when the package is on its way, or return-on-arrival instructions when the carrier offers no intercept. A person approves. The refund timing follows the path, and the order and the ticket both record it.

This is a reference listing. It documents what Fibric would read from Cancellation Window 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

  • Cancellation requests in Zendesk, Kustomer, or Gorgias, matched to the order
  • The Shopify fulfillment order: status OPEN, IN_PROGRESS, or CLOSED, and its supportedActions such as CANCEL_FULFILLMENT_ORDER
  • Warehouse progress from ShipHero webhooks: Order Allocated, Tote Complete, Order Packed Out, and Shipment Update
  • ShipStation shipments for the order: shipmentId, trackingNumber, voided, voidDate, and shipDate
  • EasyPost refund_status on a purchased label: submitted, refunded, rejected, or not_applicable
  • Carrier scans on the tracking number, which decide whether a void or an intercept still applies

Proposed actions

  • Target capability: propose orderCancel with reason CUSTOMER, restock true, and a refundMethod, when no label exists
  • Target capability: propose a ShipStation void through POST /shipments/voidlabel, or an EasyPost shipment refund, when a label exists and the carrier has not scanned it
  • Target capability: propose a UPS Delivery Intercept return to sender, or a USPS Package Intercept, when the package is already moving
  • Target capability: propose return-on-arrival: a reply with instructions and a return created at the warehouse, when no intercept is offered
  • Target capability: propose the refund timing the path implies: now for a cancel, on carrier refund for a void, on receipt for a return

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

What you can build

  • Cancel before the pick starts

    A Zendesk request on a Shopify order with no ShipHero allocation gets orderCancel with restock true and a full refund in one proposal.

    With Zendesk, Shopify, ShipHero

  • Void the label, keep the package

    A label bought in ShipStation with no carrier scan gets a void proposal, with the refund held until ShipStation returns approved, and the Kustomer conversation updated.

    With ShipStation, Kustomer

  • Turn it around in transit

    A package already scanned gets a UPS return-to-sender intercept proposal with the charge shown, or return-on-arrival instructions when the EasyPost label's service is not eligible.

    With UPS, EasyPost

Requirements

  • A help desk connector where cancellation requests arrive: Zendesk, Kustomer, or Gorgias
  • A store connector with fulfillment order status, such as Shopify
  • A label source that can void or refund labels: ShipStation or EasyPost
  • A warehouse feed for pick and pack state when labels are printed on the floor: ShipHero
  • Your refund policy per path: full refund on cancel, whether shipping is refunded on a void, and restocking on a return
Authentication
A help desk API key, a Shopify app token with write_orders, a ShipStation or EasyPost API key, and carrier API credentials, each stored per deployment.

Limits

  • Once the carrier scans the label, a void is rejected; the path becomes an intercept where the carrier offers one, or a return
  • USPS Package Intercept is refused for an item already out for delivery, and UPS quotes intercept charges per request
  • A label refund lands when the carrier processes it; EasyPost reports refund_status submitted until then
  • Warehouse state is as current as the last webhook; a pack-out that arrives after the proposal withdraws it

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 Cancellation Window ↗

Questions and answers

What choice does the approver make?
One path per request: cancel-and-refund, void, intercept, or return-on-arrival. The proposal shows the request, the fulfillment status, the warehouse's last event, the label and any carrier scan, and the refund timing that follows.
What do the order and the ticket keep?
The order carries the path chosen, the void or intercept confirmation, the refund and when it was released, the approver, and the time. The ticket gets an internal note with the same facts and the reply sent to the customer.
Could it cancel or void something on its own?
No. Cancelling, voiding, filing an intercept, refunding, and replying all wait for a person, and each approved action goes through once. If the warehouse reports a pack-out after the proposal was built, the proposal is withdrawn and rebuilt for the new state.
Ask about Cancellation Window

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy