Reference · built on requestConnectorShipping & logistics

Shippo

Rates, labels, tracking, return labels, pickups, and webhook events across carriers from the Shippo API.

About

Shippo is a multi-carrier shipping API. You create a Shipment from an address pair and a parcel, and Shippo returns a rates array from your connected carrier accounts. Buying a rate creates a Transaction with a label_url and a tracking_number. The Tracking API follows any carrier tracking number through six statuses, and webhooks post Transaction, Tracking, and Batch events to your endpoint. Orders loaded into Shippo link each label back to the order that placed it.

Through Fibric, an operator watches track_updated events for the substatus that needs a person, such as address_issue or package_lost, and proposes the next step: a return label, a pickup request, or a note on the order.

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

  • Tracking status per tracking number: PRE_TRANSIT, TRANSIT, DELIVERED, RETURNED, FAILURE, or UNKNOWN, with eta, original_eta, and tracking_history
  • Tracking substatus such as address_issue, delayed, delivery_attempted, out_for_delivery, package_damaged, or package_lost
  • Webhook events transaction_created, transaction_updated, track_updated, batch_created, and batch_purchased, each carrying a test flag
  • Rates on a Shipment, one per carrier account and service level, with the object_id needed to buy
  • Transactions with status, label_url, tracking_number, and the order they were bought against
  • Orders loaded through the Orders endpoint with order_number, order_status, line_items, and their transactions array
  • Address validation results and the carrier accounts connected to the account

Proposed actions

  • Target capability: propose buying a rate through POST /transactions/ and hand back the label as PDF, PNG, or ZPLII
  • Target capability: propose a pay-on-use return label by creating a Shipment with extra.is_return set to true
  • Target capability: propose a USPS or DHL Express pickup through POST /pickups/ for named transactions and a time window
  • Target capability: propose registering a tracking number through POST /tracks/ so its updates reach your webhook
  • Target capability: propose a refund request for an unused label through the Refunds endpoint

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

What you can build

  • Act on the substatus, not every scan

    Subscribe to track_updated and ignore routine TRANSIT scans. When substatus turns to address_issue, delayed, or package_lost, propose the customer notice and the return or reship decision for approval.

    With Carrier Exception, Stalled Shipment

  • Put the return label in the reply

    Create a return Shipment with extra.is_return for the outbound carrier and propose the pay-on-use label for the agent to send. Nothing is charged until the label is scanned.

    With Returns Triage

  • Confirm the address before the rate is bought

    Run address validation on the order's to_address and propose the corrected fields. The Transaction is created only after a person approves the change.

    With Address Repair

Requirements

  • A Shippo account with an API token from the Shippo API Portal; the full key is shown once
  • Carrier accounts connected in Shippo for the carriers you want rates from
  • An HTTPS endpoint under 200 characters that returns a 2XX status within three seconds
  • For HMAC-signed webhooks, a setup arranged with Shippo, which the docs say takes up to 10 business days
Authentication
An API token sent as Authorization: ShippoToken <token>; shippo_test_ keys return rates and test labels without charges, shippo_live_ keys buy labels that are billed.

Limits

  • Limits are per minute per endpoint, for example 500 POST calls and 4,000 single GET calls on live standard endpoints; excess returns 429
  • Tracking updates are polled from carriers; Shippo says most arrive within 2 hours of the carrier event
  • Return labels are available for USPS, FedEx, and UPS only, and only for the carrier used outbound
  • Pickups cover USPS and DHL Express only; editing or cancelling a pickup means contacting the carrier

Access and pricing

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

Request Shippo ↗

Questions and answers

Which events can Shippo post to a webhook?
Five: transaction_created, transaction_updated, track_updated, batch_created, and batch_purchased, or all as a catch-all. Each POST carries an event name, a test flag, and a data object. Your endpoint must answer 2XX within three seconds. Shippo retries twice on 408, 429, or 5XX and does not retry other 4XX responses.
How does Shippo secure a webhook?
Three options: allow-list Shippo's published IP ranges, add your own token as a query parameter on the webhook URL, or HMAC signing, which adds a signature header in the form t=<timestamp>,v1=<signature> computed with SHA-256. HMAC setup is arranged with Shippo's team rather than switched on in the portal.
Does a Shippo return label cost anything before it is used?
No. Return labels for USPS, FedEx, and UPS are pay-on-use; you are charged when the carrier scans the label. USPS return labels stay valid for one year, FedEx for two years, UPS for 100 days. Shippo swaps the addresses for you; do not swap them yourself.
Ask about Shippo

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.