JuShuiTan Sales Outbound Order Query API Field Manual (Non-QiMen · Simple)

What This API Solves

The JuShuiTan sales outbound order is the factual record of shipment and reconciliation in e-commerce supply chains. By pulling outbound orders through the non-QiMen simple version into a local SQL Server table, businesses can track fulfillment status, centralize logistics data, reconcile finances, and bridge with their in-house ERP systems. In essence, it turns scattered online outbound activity into structured, traceable local data assets.

Interface Capability Overview

• Authentication: JuShuiTan Open Platform OAuth/AppKey signature; credentials are passed via request headers.
• Endpoint: /open/orders/out/simple/query (non-QiMen simple version).
• Method: HTTP POST with a JSON body.
• Key request parameters: page_index (default 1), page_size (default 100, API cap 25), modified_begin / modified_end (incremental by modified time, interval ≤ 7 days), date_type (0=modified, 2=outbound time), status (WaitConfirm / Confirmed / Cancelled).
• Response structure: Outer code indicates error; datas.orders is the outbound order array. Each order contains header fields plus three nested collections: items, batchs, sns.
• Pagination: Page-based via page_index; iterate until an empty page is returned.
• Incremental mode: Time-window based on modified time or outbound time; the window must be ≤ 7 days or the API will refuse.

Typical Field Mapping

How to Configure It on Qeasy Cloud

On the Qeasy Cloud Data Integration Platform, this API is typically wrapped as a "JuShuiTan Sales Outbound Order Query" adapter. Here is the recommended setup path:

1. Data source connection: Create a new JuShuiTan data source, fill in AppKey/Secret, and complete authorization.
2. Adapter selection: Pick the "Sales Outbound Order (Non-QiMen · Simple)" adapter in the source component; the platform ships a pre-built request template.
3. Field mapper: The platform auto-generates a flattening template for header fields and the items nested collection. The mapper expands the items array into columns such as items_oi_id, items_sku_id, items_qty, and items_sale_price — no manual traversal needed.
4. Incremental strategy: Set date_type=2 and status=Confirmed, with a rolling 7-day window on outbound time. Qeasy Cloud manages the cursor and pagination automatically and stops when an empty page is returned.
5. Target write: Bind to SQL Server; the platform generates the batch INSERT SQL (batchexecute) using io_id as the primary key, with detail rows written via items_* columns.
6. Scheduling: Set crontab to 1 0,1,2 * * *, meaning incremental pulls at 0:00, 1:00, and 2:00 every day to cover day boundaries.

Cross-Project Practical Tips

Drawing from multiple customer projects, the following lessons are universally applicable:

1. Hard 7-day window constraint: JuShuiTan enforces that the gap between modified_begin and modified_end must not exceed 7 days. The safe approach is to slice by outbound time (date_type=2) and roll daily, so scheduling lag never crosses the window.
2. Filter by status up front: Default to pulling Confirmed (shipped) orders; run separate branch queries for WaitConfirm and Cancelled to prevent cancelled orders from polluting results.
3. items must be flattened: Line items live in a nested array, but SQL Server is relational. Before writing, flatten items into items_* columns and use io_id as the foreign key.
4. Dual safety net on keys and dedup: Use io_id as the primary key, and use the composite {{o_id}}{{modified}} for incremental dedup to guard against edge cases of empty or duplicate primary keys.
5. Address gaps need handling: The simple version does not return country/state/city/district. The receiver_country/state/city/district columns in the target table must be backfilled from another API or parsed from the merged address — never leave them blank.
6. Pagination cap awareness: The official page_size cap is 25; configuring 100 will be silently truncated. This is a common pitfall — always set it to the documented max.

Pitfall Postmortem

1. Cross-7-day window rejected: One customer scheduled the incremental script weekly; the API returned empty data with an error. Switching to a daily slice fixed it.
2. items not flattened, detail rows lost: An early version stuffed the raw JSON into SQL Server, so the frontend saw no product rows. Flattening into items_* columns made details appear.
3. page_size=100 silently truncated: A customer set 100 but only got 25 rows, assuming upstream had no more data. After lowering to 25, the pull became complete.
4. Mixing QiMen and simple versions: The two versions have different field sets (simple version has no response-side modified, status, etc.). Reusing one mapping template across both will fail — choose the template by version.
5. Cancelled orders leaked into reconciliation: Without filtering by status, cancelled orders got synced and inflated financial reconciliation amounts. Adding status=Confirmed aligned the totals.

When to Choose This

Use this API when the business needs to localize JuShuiTan sales outbound data, track shipments, or reconcile with in-house ERP/SQL Server. If you need finer-grained country/state/city/district addresses or batch/serial-level details, layer in the QiMen version or other detail APIs. For pure front-end e-commerce display, call the JuShuiTan frontend API directly — no need to land the data locally.