Build the flows in this order: Locations, Products, Shipping Requests, Fulfillments, Inventory, then inbound shipments and returns. Each one depends on IDs created by the ones before it.
| Flow | Setting | Trigger | Pipe17 calls |
|---|---|---|---|
| Locations | locations.in |
Your warehouse list changes (poll daily or on change) |
POST /locations, PUT /locations/{id}
|
| Products | products.out |
Poll or products webhook |
GET /products |
| Shipping Requests | shipments.out |
Poll or shipments webhook |
GET /shipping_requests, PUT /shipping_requests/{id}, POST /shipping_requests/{id}/reject
|
| Fulfillments | fulfillments.in |
Your system ships a package |
GET /fulfillments, POST /fulfillments
|
| Inventory | inventory.in |
Your stock levels change | POST /inventory |
| Inbound shipments |
arrivals.out, receipts.in
|
Poll arrivals; your system finishes receiving | GET /arrivals, PUT /arrivals/{id}, POST /receipts |
| Returns |
returns.out, returns.in
|
Poll returns; your system receives the items | GET /returns, PUT /returns/{id} |
Pipe17 owns step 1, the routing, step 7 and step 8; your connector owns steps 2 to 6 (sections 7.3 and 7.4).
SKU and shipping-method mapping are configured in the app. Customers set both up per integration, and Pipe17 applies them before data reaches your connector and after your connector writes it back. SKU mapping lets a product use a different SKU in your system (set under Products → All Products → Channel options → Channel SKU). Shipping-method mapping translates the shipping methods on orders into the shippingClass and shippingCarrier your system expects. Your connector reads and writes those fields as they arrive; it does not need its own mapping tables.
Comments
0 comments