Allocation

Work out where an order or basket should ship from. Nothing is written: the order, the cart and inventory are all left as they are.

Send exactly one subject: {orderId} or {cartId} for something already in Omnium, or {order} or {cart} for a basket that is not. A checkout normally sends the basket.

Name several {profileKeys} to get several rankings from one run: the plans are worked out once and each profile only contributes an order over them, so asking for three costs little more than asking for one. The first key decides {selectedPlan}.

A checkout that already holds its own availability can pass it as {inventoryOverrides} and skip Omnium's inventory read.

post/api/Allocation/Simulate

Request

  • Base URL: https://api.omnium.no (the document declares no server; this is the origin it was published from)
  • URL: https://api.omnium.no/api/Allocation/Simulate
  • Auth: API key in header Authorization

Request body

orderIdstring nullable

Id of an order already in Omnium

cartIdstring nullable

Id of a cart already in Omnium

profileKeysstring[] nullable

Profiles to rank the plans under, for example FewestShipments, Closest or LowestCost. The first is the primary one and decides the selected plan. Empty means the market's default.

replaceInventoryWithOverridesboolean

Use only the supplied availability and ignore Omnium's own inventory entirely. Off by default.

includeTraceboolean

Include the full reason trace. Off by default, since it is large

Response

Success

requestIdstring nullable

Identifies this run in the logs

outcomestring nullable

Simulated, NoFeasiblePlan, PartialPlanOnly, SkippedNotEnabled, SkippedNothingToAllocate or SkippedVslUnsupported

primaryProfileKeystring nullable

The profile that decided the selected plan

configurationVersionstring nullable

The configuration this decision was made against, so a result can be traced back

totalMsinteger

How long the engine took, in milliseconds

Changes

No recorded changes to this operation across all 1 revision of this API.