How to Submit Inventory Batches

Get Started
Functionality
Learning
Extension
Dev Tooling
APIs
Releases

Topic

Author:

Fluent Commerce

Changed on:

12 Feb 2025

Overview

Pre-requisites:

You should have knowledge of Inventory Batch
You should have knowledge of Inventory Batch Pre-Processing

This technical guide provides detailed steps on how you can submit Inventory Batches to the Fluent platform.

Authors:

Girish Padmanabha, Kirill Gaiduk

Changed on:

25 Mar 2026

Key Points

Create inventory batches using the Job API
Sample inventory batch request
Inventory batch processing details

Steps

API authentication

Authenticate against the Retailer you are sending the Inventory Batch to:

Follow the Authentication API for how to authenticate against a Retailer
The returned token will be used to authenticate all the following API calls

Set up a Job

Create a new job to execute your batches using the Job API.

Create Job Example

1POST/{{fluent.account.host}}/api/v4.1/job

1{
2    "name": "Batch Inventory Job",
3    "retailerId": "1",
4    "meta": {
5        "preprocessing": "enabled"
6    }
7}

1{
2    "id": "199"
3}

The `id` is the unique identifier of the created job
Save this `id` to use in subsequent batch requests
Use this `id` to group related batches

Inventory Batch Preprocessing Settings and Behavior in Job API

The `meta` object allows for the inclusion of additional metadata when creating a Job. The currently supported key within `meta` is `preprocessing`, which can influence whether the Batch Preprocessing Process (BPP) is utilized based on the account's settings.The behavior of the `meta.preprocessing` key is governed by the `fc.enable.batch.preprocessing` configuration setting. Below is a table outlining the expected behavior:

`fc.enable.batch.preprocessing `value	`meta.preprocessing` Value	Additional Info in Job Payload	Result
true	"preprocessing": "skip"	BPP should not be used	Do not use BPP
true	"preprocessing": "enabled"	BPP should be used	Use BPP
true	"meta": null or "meta": {}	BPP should be used	Use BPP
true	Omitted or previously created Jobs	BPP should be used	Use BPP
false	Any value	BPP should not be used (overridden)	Do not use BPP

When `fc.enable.batch.preprocessing` is `true`:
- "preprocessing": "skip"
  - Action: BPP should not be used.
- "preprocessing": "enabled" ( any value other than "skip" )
  - Action: BPP should be used.
- "meta": null or "meta": {}
  - Action: BPP should be used.
- Jobs without `meta`
  - Action: BPP should be used.
When `fc.enable.batch.preprocessing` is `false`:
- Regardless of the `meta.preprocessing` value (including `null` or omitted)
  - Action: BPP should not be used.

The fc.enable.batch.preprocessing setting takes precedence over the `meta.preprocessing` value. If fc.enable.batch.preprocessing is set to `FALSE`, BPP will not be used regardless of the `meta.preprocessing` value.
Ensure that when setting `meta.preprocessing`, only the supported values (`"skip"` or `"any value not skip"`) are used to avoid unexpected behavior.
A job-level override will affect only the batches containing inventory data created under the specific job, and this impact will remain in effect until the job expires.

Send an Inventory Batch

Create an inventory batch to be processed under the previously created job using the Job API.

Create Inventory Batch Example

1POST/{{fluent.account.host}}/api/v4.1/job/{jobID}/batch

Reminder

The URL is using the Job ID returned by the last API call, for example `199` as per the previous response: `POST/{{fluent.account.host}}/api/v4.1/job/199/batch`.

Inventory Batch Model

The Inventory Batch Model consists of:

Batch-Level Fields: Define overall batch properties.
Entities Array: Contains individual inventory items to process.

Field	Type	Mandatory?	Possible Values	Default Value	Description	Notes
action	String	✅	"UPSERT"	N/A	Specifies the operation on inventory entities (e.g., "UPSERT" to insert/update).	Must be a valid action type for inventory operations.
entityType	String	✅	"INVENTORY"	N/A	Defines the type of entity being processed.	Must be "INVENTORY".
source	String	❌	Any valid source identifier	"batch"	Identifies the origin of the batch data (e.g., "ERP", "POS").	Defaults to "batch" if not provided.
event	String	❌	Any valid event name	"InventoryChanged"	Custom event name associated with the batch operation.	Defaults to "InventoryChanged" if not provided.
catalogueRef	String	❌	Any valid catalogue reference	"DEFAULT:<retailerId>"	References the catalogue associated with the inventory batch.	Influences `catalogueType` in `ref` construction.
conditions	Object	❌	Configuration object	Uses default transient settings	Configurations like transient types and statuses are used in de-duplication checks.
entities	Array	✅	List of inventory items	N/A	List of inventory items	Follows the entities object model. Nonconforming inputs are ignored.

The conditions object has the following fields :

Field	Type	Mandatory?	Possible Values	Default Value	Description
hasRelatedInventoryQuantities	Array	❌	List of transient IQ types and statuses	Default transient types and statuses	Defines custom transient types and statuses for checking during de-duplication eg) `"hasRelatedInventoryQuantities": ``[`` {"type": "SALE", "status": "ACTIVE"}, ``{"type": "SALE", "status": "CREATED"}, ``{"type": "CORRECTION", "status": "ACTIVE"} ``]`

Each object within the `entities` array should follow this structure:

Field	Type	Mandatory?	Possible Values	Constraints	Description	Notes
locationRef	String	✅	Any valid location reference	N/A	The location reference used to match the inventory.
skuRef	String	✅	Any valid SKU reference	N/A	The SKU reference of the inventory item.
qty	Integer	✅	Any non-negative integer	N/A	The quantity to match the on-hand inventory.
correctedQty	Integer	❌	Any non-negative integer	Defaults to 0 if not provided	The current outstanding correction quantity to be saved.
type	String	❌	Any valid type identifier	N/A	Specifies the type of inventory operation (e.g., "LAST_ON_HAND").	Defaults to "LAST_ON_HAND" if not provided.
ref	String	❌	Any valid reference	Must follow `<skuRef>:<locationRef>:<catalogueType>:<type>`	A reference identifier for the inventory entity.	If not provided, constructed using `skuRef`, `locationRef`, `catalogueType`, and `type`.
status	String	❌	Any valid status value	N/A	The status of the inventory entity (e.g., "ACTIVE").
retailerId	String	✅	Any valid retailer ID	N/A	The retailer ID for which the inventory is uploading.
attributes	Object	❌	Any complex key-value pairs	Keys must be strings; values can be any valid JSON type	Additional attributes for flexible metadata storage.

1{
2  "action": "UPSERT",
3  "entityType": "INVENTORY",
4  "source": "ERP",
5  "event" :"InventoryChanged",
6  "catalogueRef": "DEFAULT:1",
7  "conditions": {
8    "hasRelatedInventoryQuantities": [
9      {"type": "SALE", "status": "ACTIVE"},
10      {"type": "SALE", "status": "CREATED"},
11      {"type": "CORRECTION", "status": "ACTIVE"}
12    ]
13  },
14  "entities": [
15    {
16      "retailerId": 1,      
17      "skuRef": "PRDREF1",
18      "locationRef": "LOCREF1",      
19      "ref": "PRDREF1:LOCREF1:DEFAULT:LAST_ON_HAND:1",
20      "qty": 100,
21      "attributes": {
22        "countryOfOrigin": "AU",
23        "manufacturerBatchNumber": "MBN1",        
24        "expiresOn": "2026-09-30T23:59:59Z"
25      }
26    },
27    {
28      "retailerId": 1,
29      "skuRef": "PRDREF1",
30      "locationRef": "LOCREF1",              
31      "ref": "PRDREF1:LOCREF1:DEFAULT:LAST_ON_HAND:2",
32      "qty": 50,
33      "attributes": {
34        "countryOfOrigin": "US",
35        "manufacturerBatchNumber": "MBN2",        
36        "expiresOn": "2026-12-31T23:59:59Z"
37      }
38    },    
39    {
40      "retailerId": 1,        
41      "skuRef": "PRDREF1",
42      "locationRef": "LOCREF1",
43      "type": "ON_ORDER",            
44      "ref": "PRDREF1:LOCREF1:DEFAULT:ON_ORDER:1",
45      "qty": 300,
46      "attributes": {
47        "associationType": "PURCHASE_ORDER",
48        "associationRef": "POREF1",
49        "expectedOn": "2026-06-01T00:00:00Z"
50      }
51    },
52    {
53      "retailerId": 1,        
54      "skuRef": "PRDREF1",
55      "locationRef": "LOCREF1",
56      "type": "ON_ORDER",      
57      "ref": "PRDREF1:LOCREF1:DEFAULT:ON_ORDER:2",      
58      "qty": 150,
59      "attributes": {
60        "parentRef": "PRDREF1:LOCREF1:DEFAULT:ON_ORDER:1",
61        "associationType": "IN_TRANSIT",
62        "associationRef": "ITREF1",
63        "expectedOn": "2026-03-01T00:00:00Z",
64        "countryOfOrigin": "US",
65        "manufacturerBatchNumber": "MBN3",        
66        "expiresOn": "2027-12-31T23:59:59Z"
67      }
68    }     
69  ]
70}

The first two records show `LAST_ON_HAND` inventory segmented by origin, batch, and expiry date
The third record shows future inventory linked to a purchase order
The fourth record shows a related `IN_TRANSIT` future inventory record linked to the purchase order through `parentRef`

1{
2  "id": "331"
3}

The returned `id` is used to check the inventory batch status in subsequent calls

Note

For detailed recommendations on inventory batch sizing, check the Inventory Batch article
For more details on inventory batch processing with batch pre-processing (BPP) enabled, see the Inventory Batch Pre-Processing: Technical Guide with Examples

Check Job Status

Use the Job API to check the status of an existing job.

Get Job Status Example

1GET/{{fluent.account.host}}/api/v4.1/job/{jobID}

1{
2  "jobId": "199",
3  "status": "OPEN",
4  "batch": [
5    {
6      "batchId": "331",
7      "status": "COMPLETE",
8      "createdOn": "2022-10-06T00:31:08.104+0000"
9    }
10  ],
11  "createdOn": "2022-10-06T00:31:08.104+0000"
12}

Check Inventory Batch Status

View the status of a specific batch. This provides more detailed information than the job status.

Get Inventory Batch Status Example

The request requires the Job ID and Batch ID returned by previous API calls.

1GET/{fluent.account.host}/api/v4.1/job/{jobID}/batch/{batchID}

1{
2  "batchId": "331",
3  "entityType": "INVENTORY",
4  "status": "COMPLETE",
5  "start": 1,
6  "count": 10,
7  "total": 0,
8  "results": [],
9  "createdOn": "2022-10-06T00:36:09.344+0000"
10}

Related artifacts

UpsertInventoryQuantity

Inventory Catalog Workflow Template

Virtual Catalog Workflow Templates

Authors:

Girish Padmanabha, Kirill Gaiduk

Changed on:

23 Mar 2026

Overview

Inventory payloads can include additional Inventory Quantity attributes to capture richer stock context.This article explains how to use the `attributes` object to include additional data in inventory payloads. It supports both simple key-value pairs and custom JSON structures to meet diverse business requirements - whether you’re:

managing detailed product information
optimizing warehouse processes
or integrating with custom workflows

The Inventory Reference Module supports a set of reference attributes that are persisted automatically, while custom attributes provide additional flexibility.

Key points

Prerequisites: To fully leverage the extended attributes functionality within the inventory payload, ensure that you are using the Inventory Reference Module v2.3.0 or later
Flexible attribute structure: The `attributes` object supports any combination of key-value pairs, including complex JSON structures and arrays. This flexibility allows you to customize the data sent in your inventory payloads to meet specific business needs
Use reference attributes first: Certain key attributes (such as `associationType`, `associationRef`, `parentRef`, `expectedOn`, `expiresOn`, `condition`, `storageAreaRef`, `supplier`, `manufacturer`, `manufacturerBatchNumber`, `countryOfOrigin`, and `channel`) will be directly updated in the Inventory Quantity associated with the incoming record, facilitating seamless integration with existing fields
Use segment fields for flexible key-value extensions: `segment1`, `segment2`, and `segment3` provide flexibility for additional flat classification data without introducing new custom attributes
Custom attribute availability: Any custom attributes that you include in the `attributes` object will be available in workflows via `inventoryPosition.inventoryQuantity.attributes.<fieldName>`. This enables you to incorporate custom data into rule-based processes or other logic tailored to your business requirements

Attribute Strategy

Inventory payloads can include multiple types of attributes depending on the business scenario.When extending inventory data, follow this general approach:

This approach ensures compatibility with reference workflows and reduces the need for custom processing logic.

Reference Attributes

These attributes represent common inventory concepts already supported by the reference inventory data model and workflows.

Specific Segmentation Attributes

When designing inventory payloads, start with the dedicated Inventory Quantity attributes supported by the Inventory Reference Module.These attributes are automatically persisted by the reference `UpsertInventoryQuantity` rule, meaning they can be stored and used in workflows without additional mapping logic. Using these attributes ensures that payloads remain aligned with the reference inventory data model and supports common inventory scenarios such as:

Use Cases

Future Inventory and Stock Segmentation

Promise and Reserve Stock Before It Arrives

Track and Allocate Stock by Origin and Expiry Date

Isolate and Trace Stock by Manufacturer and Batch

Allocate and Manage Stock by Sales Channel

Click here to see all

Flexible Segmentation Attributes

For additional flat classification data that does not correspond to the existing specific attributes, use the segment fields:

`segment1`
`segment2`
`segment3`

Recommended Attributes Table

The following attributes are integrated into the platform’s inventory management workflows. This means that these fields will be directly updated in the Inventory Quantity associated with the incoming record, ensuring seamless operation and enhanced performance.

Attribute key	Description	Example	Use case(s)	Notes
`associationType`	Defines the type of operational or business entity linked to the Inventory Quantity	`PURCHASE_ORDER`	Future inventory Reservation linkage Operational traceability	Use together with `associationRef` Common examples include purchase orders, in-transit shipments, and fulfillment reservations
`associationRef`	Identifies the specific operational or business record linked to the Inventory Quantity	`POREF1`	Linking stock to a specific: purchase order ASN in-transit shipment or fulfillment record Improving procurement tracking Enhancing order accuracy	Use with `associationType` to anchor the Inventory Quantity to an external business event or document
`parentRef`	Links the Inventory Quantity to a parent Inventory Quantity to model a hierarchy	`PRDREF1:LOCREF1:DEFAULT:ON_ORDER`	Future inventory hierarchies (`PURCHASE_ORDER` -> `IN_TRANSIT`) Reservation anchoring Segmented stock trees	Useful when modeling derived inventory states such as reservations under a specific parent quantity
`expectedOn`	Indicates when the Inventory Quantity is expected to become available	`2026-05-01T00:00:00Z`	Promise and reserve stock before it arrives Planning for space allocation and staffing Ensuring timely product availability	Date (ISO-8601 format) Use for future inventory, not forecasts
`expiresOn`	Indicates when the Inventory Quantity expires or becomes ineligible for allocation	`2026-12-31T23:59:59Z`	Managing stock rotation Reducing waste Ensuring compliance with health and safety regulations	Date (ISO-8601 format) Supports expiry-aware allocation patterns such as First Expired, First Out (FEFO)
`condition`	Describes the physical or operational condition of the inventory	`NEW`	Physical stock partitioning by condition or lifecycle constraints Enabling categorization of items for different sales channels allocation	Common examples include new, refurbished, and damaged
`storageAreaRef`	Identifies the storage area where the Inventory Quantity is held within a location	`LOCREF1:SAREF1`	Optimizing space utilization Reducing retrieval time Improving warehouse efficiency	Useful for representing storage-specific inventory context inside a single location
`supplier`	Identifies the supplier associated with the Inventory Quantity	`SUPREF1`	Tracking supplier performance Managing vendor relationships Optimizing supply chain efficiency	Enables supplier-level inventory segmentation and sourcing decisions across inventory pools
`manufacturer`	Identifies the manufacturer associated with the Inventory Quantity	`MANREF1`	Manufacturer traceability across segmented inventory pools	Often used together with `manufacturerBatchNumber`
`manufacturerBatchNumber`	Captures the manufacturer batch identifier for the Inventory Quantity	`MBN1`	Tracking production details Quality control Recall management	Supports batch-level traceability and quality isolation scenarios
`countryOfOrigin`	Identifies the country where the inventory was produced or sourced	`AU`	Compliance with import/export regulations Supporting marketing strategies emphasizing local products	Supports compliance, regulatory, and market-eligibility sourcing scenarios
`channel`	Identifies the sales channel associated with the Inventory Quantity	`ONLINE`	Allocate and manage stock by sales channel	Channel differentiation is primarily expressed through reservations and customer-facing availability views
`segment1-3`	Flexible segmentation fields for additional inventory classification	`PROMO`	Additional physical or commercial segmentations	Use for flat extensions when a dedicated supported attribute does not fit the business meaning

Custom Attributes

In addition to the reference-supported attributes, inventory payloads can include custom attributes inside the `attributes` object.Custom attributes are useful when the payload needs to represent:

nested JSON structures
arrays
complex business-specific metadata

These attributes remain available in workflows and can be accessed using `inventoryPosition.inventoryQuantity.attributes.<fieldName>`. However, processing these attributes typically requires custom workflow logic or rules, as they are not automatically mapped by the reference `UpsertInventoryQuantity` rule.This allows you to incorporate your custom data into rule-based processes or other logic tailored to your specific business scenarios.

Recommended practice

For simple key-value extensions, use `segment1`, `segment2`, and `segment3` instead of introducing new custom fields
Only introduce custom attributes when you need to represent more complex structures that can not be expressed through the supported fields

Naming Guidance

When designing new inventory payloads, prefer the reference-supported attribute keys whenever they match your business meaning. For example:

Prefer	Instead of
`expiresOn`	`expiryDate`
`supplier`	`supplierId`
`manufacturerBatchNumber`	custom batch identifiers
`segment1-3`	new flat custom attributes

Using standard attribute names improves compatibility with reference workflows and simplifies inventory data processing.

Batch Pre-Processing and Attribute-Only Updates

Batch Pre-Processing (BPP) determines whether a record has changed by comparing the Inventory Quantity's identity, qty, optional status, and transient inventory conditions. See more details in the Inventory Batch Pre-Processing: Technical Guide with Examples. Changes to other Inventory Quantity attributes (e.g., `associationRef`, `parentRef`, `expectedOn`, `expiresOn`, `condition,` `segment1-3`) are not evaluated as part of this comparison. If an update changes only these attributes and does not modify `qty` or `status`, the record may be treated as unchanged and filtered from processing.

Expected Delivery Date Shift Tip

For scenarios where the expected delivery date changes, such as a delayed or rescheduled shipment, the recommended approach is to:

set the existing Inventory Quantity record to `INACTIVE`
create a new Inventory Quantity record with the updated `expectedOn` value

This approach represents the updated future inventory state as a new record rather than modifying the existing one.

Related content

Knowledge Tracks Related To This Topic

All about Big Inventory

Fluent Big Inventory - Features Overview

Getting Started with Fluent Big Inventory

Inventory Ingestion

Inventory Batch

How to Submit Inventory Batches

Inventory Modeling Guide

Future Inventory - Data Model and API Overview

Stock Segmentation - Data Model and API Overview

Fluent Big Inventory Web App

Metrics Overview

How Metrics works

Metrics usage for Platform Observability

Inventory Feeds

How do Inventory Feeds work

Send an Inventory Batch

Create an inventory batch to be processed under the previously created job using the Job API.

Create Inventory Batch Example

1POST/{{fluent.account.host}}/api/v4.1/job/{jobID}/batch

Reminder

The URL is using the Job ID returned by the last API call, for example `199` as per the previous response: `POST/{{fluent.account.host}}/api/v4.1/job/199/batch`.

Inventory Batch Model

The Inventory Batch Model consists of:

Batch-Level Fields: Define overall batch properties.
Entities Array: Contains individual inventory items to process.

Field	Type	Mandatory?	Possible Values	Default Value	Description	Notes
action	String	✅	"UPSERT"	N/A	Specifies the operation on inventory entities (e.g., "UPSERT" to insert/update).	Must be a valid action type for inventory operations.
entityType	String	✅	"INVENTORY"	N/A	Defines the type of entity being processed.	Must be "INVENTORY".
source	String	❌	Any valid source identifier	"batch"	Identifies the origin of the batch data (e.g., "ERP", "POS").	Defaults to "batch" if not provided.
event	String	❌	Any valid event name	"InventoryChanged"	Custom event name associated with the batch operation.	Defaults to "InventoryChanged" if not provided.
catalogueRef	String	❌	Any valid catalogue reference	"DEFAULT:<retailerId>"	References the catalogue associated with the inventory batch.	Influences `catalogueType` in `ref` construction.
conditions	Object	❌	Configuration object	Uses default transient settings	Configurations like transient types and statuses are used in de-duplication checks.
entities	Array	✅	List of inventory items	N/A	List of inventory items	Follows the entities object model. Nonconforming inputs are ignored.

The conditions object has the following fields :

Field	Type	Mandatory?	Possible Values	Default Value	Description
hasRelatedInventoryQuantities	Array	❌	List of transient IQ types and statuses	Default transient types and statuses	Defines custom transient types and statuses for checking during de-duplication eg) `"hasRelatedInventoryQuantities": ``[`` {"type": "SALE", "status": "ACTIVE"}, ``{"type": "SALE", "status": "CREATED"}, ``{"type": "CORRECTION", "status": "ACTIVE"} ``]`

Each object within the `entities` array should follow this structure:

Field	Type	Mandatory?	Possible Values	Constraints	Description	Notes
locationRef	String	✅	Any valid location reference	N/A	The location reference used to match the inventory.
skuRef	String	✅	Any valid SKU reference	N/A	The SKU reference of the inventory item.
qty	Integer	✅	Any non-negative integer	N/A	The quantity to match the on-hand inventory.
correctedQty	Integer	❌	Any non-negative integer	Defaults to 0 if not provided	The current outstanding correction quantity to be saved.
type	String	❌	Any valid type identifier	N/A	Specifies the type of inventory operation (e.g., "LAST_ON_HAND").	Defaults to "LAST_ON_HAND" if not provided.
ref	String	❌	Any valid reference	Must follow `<skuRef>:<locationRef>:<catalogueType>:<type>`	A reference identifier for the inventory entity.	If not provided, constructed using `skuRef`, `locationRef`, `catalogueType`, and `type`.
status	String	❌	Any valid status value	N/A	The status of the inventory entity (e.g., "ACTIVE").
retailerId	String	✅	Any valid retailer ID	N/A	The retailer ID for which the inventory is uploading.
attributes	Object	❌	Any complex key-value pairs	Keys must be strings; values can be any valid JSON type	Additional attributes for flexible metadata storage.

1{
2  "action": "UPSERT",
3  "entityType": "INVENTORY",
4  "source": "ERP",
5  "event" :"InventoryChanged",
6  "catalogueRef": "DEFAULT:1",
7  "conditions": {
8    "hasRelatedInventoryQuantities": [
9      {"type": "SALE", "status": "ACTIVE"},
10      {"type": "SALE", "status": "CREATED"},
11      {"type": "CORRECTION", "status": "ACTIVE"}
12    ]
13  },
14  "entities": [
15    {
16      "retailerId": 1,      
17      "skuRef": "PRDREF1",
18      "locationRef": "LOCREF1",      
19      "ref": "PRDREF1:LOCREF1:DEFAULT:LAST_ON_HAND:1",
20      "qty": 100,
21      "attributes": {
22        "countryOfOrigin": "AU",
23        "manufacturerBatchNumber": "MBN1",        
24        "expiresOn": "2026-09-30T23:59:59Z"
25      }
26    },
27    {
28      "retailerId": 1,
29      "skuRef": "PRDREF1",
30      "locationRef": "LOCREF1",              
31      "ref": "PRDREF1:LOCREF1:DEFAULT:LAST_ON_HAND:2",
32      "qty": 50,
33      "attributes": {
34        "countryOfOrigin": "US",
35        "manufacturerBatchNumber": "MBN2",        
36        "expiresOn": "2026-12-31T23:59:59Z"
37      }
38    },    
39    {
40      "retailerId": 1,        
41      "skuRef": "PRDREF1",
42      "locationRef": "LOCREF1",
43      "type": "ON_ORDER",            
44      "ref": "PRDREF1:LOCREF1:DEFAULT:ON_ORDER:1",
45      "qty": 300,
46      "attributes": {
47        "associationType": "PURCHASE_ORDER",
48        "associationRef": "POREF1",
49        "expectedOn": "2026-06-01T00:00:00Z"
50      }
51    },
52    {
53      "retailerId": 1,        
54      "skuRef": "PRDREF1",
55      "locationRef": "LOCREF1",
56      "type": "ON_ORDER",      
57      "ref": "PRDREF1:LOCREF1:DEFAULT:ON_ORDER:2",      
58      "qty": 150,
59      "attributes": {
60        "parentRef": "PRDREF1:LOCREF1:DEFAULT:ON_ORDER:1",
61        "associationType": "IN_TRANSIT",
62        "associationRef": "ITREF1",
63        "expectedOn": "2026-03-01T00:00:00Z",
64        "countryOfOrigin": "US",
65        "manufacturerBatchNumber": "MBN3",        
66        "expiresOn": "2027-12-31T23:59:59Z"
67      }
68    }     
69  ]
70}

The first two records show `LAST_ON_HAND` inventory segmented by origin, batch, and expiry date
The third record shows future inventory linked to a purchase order
The fourth record shows a related `IN_TRANSIT` future inventory record linked to the purchase order through `parentRef`

1{
2  "id": "331"
3}

The returned `id` is used to check the inventory batch status in subsequent calls

Note

For detailed recommendations on inventory batch sizing, check the Inventory Batch article
For more details on inventory batch processing with batch pre-processing (BPP) enabled, see the Inventory Batch Pre-Processing: Technical Guide with Examples

How to Submit Inventory Batches

Overview

Submit Inventory Batches With Attributes

Key Points

Steps

API authentication

Set up a Job

Create Job Example

Send an Inventory Batch

Create Inventory Batch Example

Inventory Batch Model

Check Job Status

Get Job Status Example

Check Inventory Batch Status

Get Inventory Batch Status Example

Related artifacts

UpsertInventoryQuantity

Inventory Catalog Workflow Template

Virtual Catalog Workflow Templates

Send Enhanced Inventory Attributes in Your Payloads

Overview

Key points

Attribute Strategy

Reference Attributes

Specific Segmentation Attributes

Use Cases

Flexible Segmentation Attributes

Recommended Attributes Table

Custom Attributes

Naming Guidance

Batch Pre-Processing and Attribute-Only Updates

Related content

Inventory Modeling Guide

Future Inventory - Data Model and API Overview

Stock Segmentation - Data Model and API Overview

Related content

Inventory Batch Pre-Processing

How Inventory Batch Pre-Processing works

Enable Batch Inventory Pre-Processing

Inventory Batch Pre-Processing: Technical Guide with Examples

Job API

Fluent Commerce

Knowledge Tracks Related To This Topic

Building Blocks

Browse By Type

Helpful Resources

Quick Links

API authentication

Set up a Job

Create Job Example

Send an Inventory Batch

Create Inventory Batch Example

Inventory Batch Model

Check Job Status

Get Job Status Example

Check Inventory Batch Status

Get Inventory Batch Status Example

Use Cases