Guides
Start typing to search…

Key Concepts

ShipMonk App Core Concepts

Orders

Orders have three ways to get into your ShipMonk App:

  1. API
  2. Import via ShipMonk Web App
  3. Manual Creation via ShipMonk Web App

All orders follow this same basic flow: Unfulfilled, Fulfillment in Progress, Fulfilled. Orders can only be canceled in ShipMonk from the Unfulfilled order status. Orders which have progressed to Fulfillment in Progress and Fulfilled will need to be marked for return in order to stop them from being sent to a customer.

flowchart TD
    A[Unfulfilled]
    B[Fulfillment in Progress]
    C[Fulfilled]
    D[Order Canceled]

    A --> B
    B --> C
    A --> D

    classDef unfulfilled fill:#ffcccc,stroke:#ff0000,stroke-width:2,color:#000;
    classDef inprogress fill:#cce0ff,stroke:#0066ff,stroke-width:2,color:#000;
    classDef fulfilled fill:#ccffcc,stroke:#00aa00,stroke-width:2,color:#000;
    classDef canceled fill:#fff2cc,stroke:#ffcc00,stroke-width:2,color:#000;

    class A unfulfilled
    class B inprogress
    class C fulfilled
    class D canceled

Inventory

Products have numerous inventory classifications.

Inventory Statuses:

  • Expected inventory: The anticipated inbound sum of products across all inbound receivings.
  • Quarantined Inventory: Inventory which has been set aside for a variety of reasons. e.g. Regulatory clearance
  • Allocated Inventory: Inventory that is not available because it has already been allocated to an order (orders that are Queued to Submit, or already Submitted).
  • Inventory Available: All inventory which is not allocated to orders. Includes inbound
  • Inventory on Hand: All inventory which is physically in ShipMonk's warehouse(s). Excludes inbound
  • Final Inventory: The sum of all available inventory, less the number of units in action required and backorders. If final inventory is negative, it means you need that negative number of units to be able to fulfill all orders, in the system.

For additional information regarding inventory statuses, please view this help doc.

Lots: To help manage aging inventory and track batches of products merchants can use lots to view all inventory statuses by a specific sub-group of products. All products in ShipMonk are allocated to orders via FIFO (First In, First Out), when an expiration date is included on a lot, we prioritize FEFO (First Expiring, First Out). Lots are not enabled by default when you set up your ShipMonk account. You will first need to enable Lot Handling, which will grant the ability to enable lots at the product level within the ShipMonk web app. For more information regarding lots and enabling them on your account, please reference this help doc.

Receivings

Receivings can be thought of as inbound shipments to ShipMonk warehouses. Receivings have four statuses which vary, depending upon the count and inspection of included products. For more information, please reference these receiving guidelines.

  • Partial: One or more of the SKUs expected in an inbound shipment was not found.
  • Short: One or more of the units on a receiving didn't have a count that matched the expected inbound quantity (too few).
  • Over: One or more of the units on a receiving didn't have a count that matched the expected inbound quantity (too many).
  • Complete: All SKUs and units of the received shipment matched the expected quantities and were checked in.

Returns

Once an order has reached the pick in progress processingStatus, an order can only be recalled by issuing a return. Returns allow you to create and track customer returns (RMAs) through the API, specifying the warehouse, return reason, expected items, and desired actions (e.g., return to inventory or mark as damaged). Each return has a unique RMA identifier and progresses through statuses from creation to receipt, with detailed tracking of expected versus received quantities and lot information. For more information regarding returns and how they can be issued, please reference this return process doc.

Webhooks

Webhooks allow ShipMonk to send real-time notifications to external systems when key events occur, such as order shipments, status changes, returns, and receiving updates. They support HTTP Basic Authentication for security and include an X-Sm-Signature header for data integrity verification using HMAC-SHA512. Webhooks expect a 2xx response to confirm successful delivery and will retry failed deliveries up to 100 times with 5-minute intervals between attempts.


Account Settings

Stores

The concept of a Store in ShipMonk is synonymous with a merchant's sales channel or marketplace where orders originate. Each ShipMonk account is designed to accommodate a dedicated Store for every e-commerce platform a merchant utilizes, alongside an additional Store for manually entered orders via the ShipMonk web app. For more basic information regarding stores and how to set them up, please reference this documentation. From a technical perspective stores enable:

  • A Store is where you can set default ship from/return addresses, set order auto-submission, enable gift messaging, enable order merging, enable inventory sync and more.
  • All integrations have a unique store, but more stores can exist than integrations.
  • Multiple ShipMonk API stores can be created if store settings need to differ.
  • Once you have an API key, you are able to CRUD an order in any store within your account.
flowchart TD
    A[Store]
    B[Shipping Mapping]
    C[Tax Information]
		D[Order Logic]

    A --> B
    A --> C
		B --> D
    C --> D

Integrations

Integrations refer to the technical connections that allow ShipMonk to communicate with various e-commerce platforms, marketplaces, and other third-party services. An integration is the underlying mechanism that enables data exchange between ShipMonk and a specific store or service.​ More information about integrations can be found here.


flowchart TD
    A[Integration]
    B[Orders]
    C[Inventory]
    D[Documents]

		A <--> B
		A <--> C
    A <--> D

Trading Partners

Trading Partner in the ShipMonk platform is a key field that enables merchants to designate the specific retailer, distributor, or business entity associated with an order. It represents the external party with whom ShipMonk is either exchanging documents via Electronic Data Interchange (EDI) or fulfilling orders on behalf of. This designation allows merchants to configure order rules, packing inserts, and fulfillment workflows tailored to each trading partner. The Trading Partner entity is essential for orchestrating unique SLAs for various marketplaces which may be connected to ShipMonk via a single integration. e.g. A merchant may connect to ShipMonk via an EDI service, and then connect many marketplaces to that EDI. With trading parters set up for each business entity, ShipMonk can properly route, pack, pick and ship orders however necessary. More information regarding trading partners can be found here.



flowchart LR
    A[EDI Connection]
    B[Trading Partner: Target+]
    C[Trading Partner: TJX]
		D[Trading Partner: Dropship Retailer]

		A <--> B
    A <--> C
    A <--> D

Automation Rules

​Automation Rules in ShipMonk allow merchants to create "If X, then Y" workflows to automate common fulfillment behaviors, reducing manual errors, saving time, and improving agility in order management.

Each automation rule consists of three main components:

  • Trigger: Defines when the rule should run.
  • Conditions: Specifies what must be true for the rule to apply.
  • Actions: Determines what the system should do if the conditions are met.

For example: "If an order contains SKU BUNDLE-X (condition), then change the requested shipping method to Economy (action), when the order is updated (trigger)."

Updated about 1 month ago

What’s Next