FeedAMP Order API V2

The FeedAMP Order API V2 provides enhanced control over your order processing by allowing you to define how orders are managed, fulfilled, and updated. This event-driven system adapts to your existing processes, giving you the flexibility to automate workflows according to your specific requirements.

Use this API to:

• Authenticate and manage API access
• Define events and order processes
• Submit fulfillments at the item level
• Process returns and refunds
• Manage cancellations and refunds

How It Works

FeedAMP Order API V2 is an event-driven order processing system. Orders are imported from marketplaces on a configurable schedule, generating a new-order event. After this, your workflow configuration determines all the actions that are taken on that order.

Authentication

FeedAMP Order API V2 uses the same authentication endpoints and headers as the FeedAMP Order API v1.

New Features Since V1

More ways to filter your incoming orders:

• Optionally import orders with PENDING marketplace state
• Request orders filtered by the last time status changed

Additional improvements:

• Submit individual item fulfillments and cancellations, instead of needing to consolidate the whole order for every submission
• Invoke channel-specific operations outside of the typical FeedAMP order workflow

Example Call Structure

1. Get token (only when required)

   • Call GET /get_token with your username and password in Basic Authentication to get an auth token.
   • Save this token until it expires and use it in all your requests.
   • No more than 100 tokens can be active at any one time.

2. Fetch orders

   • Example A: Orders that configured workflow has determined are ready, using feedamp_status
     • Call GET /orders?feedamp_status=IMPORTED
   • Example B: Orders with a particular marketplace status that have been updated since the last poll:
     • Call GET /orders?normalized_marketplace_state=AWAITING_SHIPMENT&marketplace_state_changed_after= last_fetched_orders
     • Your application would need to remember the timestamp last_fetched_orders
   • Example C: Orders in any state (including PENDING) that have recently imported
     • Call GET /orders?imported_after= last_fetched_orders
     • Your application would need to remember the timestamp last_fetched_orders
     • API consumer must maintain their own records of order states, and fulfill orders after the marketplace_state changes to AWAITING_SHIPMENT.

3. Confirm order

   • Confirmation is how your application notifies FeedAMP that you have ingested the order.
   • Confirmation also allows your application to communicate its internal order identifier to FeedAMP.
   • Call /orders/:order_id/confirm
   • If feasible, include request body {"merchant_order_number":":your_order_identifier:"}

4. Fulfill order lines

   • Pack items and note which order lines and quantities are in each package.
   • Call POST /orders/{order_id}/fulfillments with Fulfillment model:

     1
     {
     2
       "fulfillment_type": "shipment",
     3
       "fulfillment_lines": [
     4
         { "line_id": "1", "quantity": 1 },
     5
         { "line_id": "2", "quantity": 2 }
     6
       ],
     7
       "shipment": {
     8
         "shipped_date": "2020-01-01T12:34:56-05:00",
     9
         "carrier": "UPS",
     10
         "tracking_number": "1Z123XYZ"
     11
       }
     12
     }
   • FeedAMP Order V2 can be configured to immediately send individual shipments to supported marketplaces.

5. Cancel order lines

   • Call POST /orders/{order_id}/cancellations with Cancellation model:

     1
     {
     2
       "cancellation_lines": [
     3
         { "line_id": "3", "quantity": 3 },
     4
         { "line_id": "4", "quantity": 4 }
     5
       ],
     6
       "reason": "out_of_stock"
     7
     }
   • FeedAMP Order V2 can be configured to immediately send individual cancellations to supported marketplaces.

6. When all the items in the order have been fulfilled or cancelled, workflow can be configured to send whole-order fulfillment to supported marketplaces.

Additional Notes

• All date-time fields use RFC 3339 formatting, including time zone: 1999-12-31T23:59:59-05:00
• It is expected that REST API integrations are able to tolerate additive (i.e. non-breaking) updates without requiring advance notice.