- Inventory management solution release notes
- June 2026
- May 2026
- April 2026
- Commercial pricing solution release notes
- Merchandising solution release notes
Supply Chain & Retail Solutions release notes
June 3, 2026
New: Integration walkthrough
A new Integration walkthrough page in the API Guide walks customer IT teams, solution engineers, and support engineers through the four stages of integrating with the Data Ingestion API: extract, transform, align field names, and batch + send. Each stage has the relevant API calls embedded inline — GET /api/v2/schema/solutions to confirm what's rolled out, POST /api/v2/objects/{objectName} for ingesting batches (with a dryRun variant), and POST /api/v2/schema/{objectName}/add-attribute for adding tenant-specific columns — alongside Snowflake COPY INTO and Redshift UNLOAD recipes for the extract step. Designed as a single one-stop guide rather than scattered references.
Bulk-ingest guide: folder-load sort order spelled out
The Historical data ingestion guide's "File or folder?" section now spells out the folder-load sort-order rules. Lexicographic sort gives the right order when filenames encode order as zero-padded numbers (part-0001.csv) or ISO-style date prefixes (2024-06-01.csv) — both forms warehouse exports produce by default. It gives the wrong order for non-padded part numbers, DD-MM-YYYY or MM-DD-YYYY date names, or month-name files like January_report.csv. The doc now lists each failure case in a comparison table and recommends the safe naming pattern.
June 2, 2026
Historical data ingestion guide
A new guide covers loading large historical datasets (millions to billions of rows) into the Data Ingestion API. It explains the design considerations for at-scale loads — streaming, dynamic batching, rate-limiting, foreign-key ordering, checkpointing, and failed-row handling — and provides a self-contained Python reference script you can configure and run. See Historical data ingestion.
Bulk-ingest script
The Python reference script in the historical-data-ingestion guide:
- Loads one table per run with a minimal
CONFIGblock (csv_path,object_name,solution_name,operation_type,parallel). To load several tables, run the script once per table. - Accepts a folder of CSV part-files as the source, in addition to a single CSV file. Chunked exports are loaded in sorted filename order.
- Reads gzip-compressed CSVs transparently, detected from the
.gzextension. - Recognises both empty string (Redshift
UNLOADdefault) and\N(SnowflakeCOPY INTOdefault) as null markers. - Fails fast if a CSV row has more cells than the header, instead of silently shifting data into the wrong columns.
- Tolerates uncastable cells (e.g.
"abc"in an integer column) by passing them through to the API as raw strings, so one bad cell becomes one rejected row, not a stopped load. - Exposes a
paralleltoggle forUPSERTloads where a primary key can appear more than once in the source.
The guide also includes warehouse-specific UNLOAD / COPY INTO recipes for Snowflake and Redshift, and a section on re-running the script (resume behaviour, where checkpoint and failed-row files live, how to start fresh).
Operation type guidance
The API guide now frames the choice between APPEND and UPSERT around what the downstream solution needs from the data — current state vs full history — rather than around data type.
Add-column endpoint: nullability guidance
The Add a new column section now has a Controlling required-ness and nullability on the new column subsection. It documents that required and nonNull are independent validators in the add-column path and lays out the four valid combinations as a small table:
- Key required + value non-null
- Key required + value nullable
- Key optional + value non-null
- Key optional + value nullable
The subsection also calls out the API-enforced mutual exclusion of defaultValue and nonNull — sending both returns 400 Bad Request with the exact error message the API produces ("Cannot use 'nonNull' validation with defaultValue. defaultValue ensures the field always has a value."), so customers can match the failure in their integration logs.
These guarantees apply equally to the Inventory Management solution; the doc clarification is shared across all Supply Chain & Retail solutions that use the Data Ingestion API.