This page explains how Operators and Customer Admins can find and review orders blocked by Buying Policies, and how to pivot to reasons and unblock actions.

Key points

• Use the list endpoint with blockedByBuyingPolicy=true to retrieve blocked orders.
• Filter by blocking policy types (e.g., MANUAL_VALIDATION) to focus your view.
• Do not rely on a bespoke “blocked” status; the filter is the stable contract.
• From a single order, fetch blocking reasons and, if allowed, force validation and review audit history.

🔎 Find blocked orders

List endpoint

• GET /v1/logistic-orders - ADM-ORDER-551

Core filters

• blockedByBuyingPolicy=true - returns only orders blocked by a policy
• blockingPolicyTypes=[...] - limits to specific policy buckets (e.g., MANUAL_VALIDATION, CREDIT_CONTROL, QUOTAS)
• Standard pagination applies

Example

GET /v1/logistic-orders?blockedByBuyingPolicy=true&blockingPolicyTypes=MANUAL_VALIDATION&pageSize=50

Your specs note that a special “blocked” status may be phased out; prefer the filters above for forward compatibility.

🗺️ Views you can build

• By policy: filter on blockingPolicyTypes to slice Credit vs Quotas vs Manual Validation.
• Global: blockedByBuyingPolicy=true without further scoping.
• By account: combine with your account scoping filters.
• Per order: jump to an order’s details and fetch reasons.

📈 Blocked list - flow

graph LR
  %% ---------- Flow ----------
  UI[List blocked orders view] --> Q[GET /v1/logistic-orders<br>ADM-ORDER-551]
  Q --> F{Filters}
  F --> T1[blockedByBuyingPolicy<br>= true]
  F --> T2[blockingPolicyTypes<br>= Manual Validation or Credit Control or Quotas]
  Q --> P{Has next token}
  P -->|Yes| N[GET next page]
  P -->|No| D[Done]

  %% ---------- Styles ----------
  classDef total fill:#e8f1ff,stroke:#2f6feb,stroke-width:2px,color:#0b3d91;
  classDef diff fill:#fff4e5,stroke:#f59e0b,stroke-width:2px,color:#7a3e00;
  classDef visible fill:#ecfdf5,stroke:#10b981,stroke-width:2px,color:#064e3b;
  classDef resp fill:#f2f4f7,stroke:#475569,stroke-width:2px,color:#111827;

  class UI total;
  class Q diff;
  class F,T1,T2 resp;
  class P resp;
  class N visible;
  class D resp;

  style UI rx:8,ry:8
  style Q rx:8,ry:8
  style F rx:8,ry:8
  style T1 rx:8,ry:8
  style T2 rx:8,ry:8
  style P rx:8,ry:8
  style N rx:8,ry:8
  style D rx:8,ry:8

🧾 Drill down: reasons and actions

From a selected blocked order:

• Fetch reasons
  • GET /v1/buying-policies/blocking-reasons - ADM-BUYING-POLICY-552
• Force validation (unblock)
  • POST /v1/logistic-orders/unblock - ADM-ORDER-150
• Audit history
  • GET /v1/logistic-orders/:logisticOrderId/unblock-history - ADM-ORDER-550

Order details — flow

graph LR
  O[Open order detail] --> R[GET blocking reasons<br>ADM-BUYING-POLICY-552]
  O --> U[POST unblock<br>ADM-ORDER-150]
  U --> H[GET unblock history<br>ADM-ORDER-550]
  R --> H

  %% ---------- Styles ----------
  classDef inter fill:#fee2e2,stroke:#ef4444,stroke-width:2px,color:#7f1d1d;
  classDef visible fill:#ecfdf5,stroke:#10b981,stroke-width:2px,color:#064e3b;
  classDef resp fill:#f2f4f7,stroke:#475569,stroke-width:2px,color:#111827;

  class O resp;
  class R,U,H visible;

  style O rx:8,ry:8
  style R rx:8,ry:8
  style U rx:8,ry:8
  style H rx:8,ry:8

✅ Operator checklist

• Always include blockedByBuyingPolicy=true when listing blocked orders.
• Narrow down with blockingPolicyTypes to focus teams and queues.
• Use reasons to communicate precisely to stakeholders.
• Use unblock only when policy criteria are satisfied or a proper override is warranted; history will capture the action.

🔗 API quicklinks

• GET /v1/logistic-orders - ADM-ORDER-551
• GET /v1/buying-policies/blocking-reasons - ADM-BUYING-POLICY-552
• POST /v1/logistic-orders/unblock - ADM-ORDER-150
• GET /v1/logistic-orders/:logisticOrderId/unblock-history - ADM-ORDER-550