Supply Chain & Retail Solutions release notes

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.

Every Commercial Pricing dataset page in the User Guide and its matching resource page in the API Guide now carry a short cross-link to each other. Readers can jump from business context (purpose, usage notes) to the canonical technical schema (data types, validation rules, request/response examples) in one click, in either direction. The two guides remain separate — the cross-links just make navigation between them explicit. Affects the customer, merchant, project, list price, product cost, competitor price, quote line, sale, region, and product pages.

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.

The Commercial Pricing data documentation has been brought in line with the canonical schema. Several columns have been renamed to their canonical names, a few tenant-specific columns that had crept into the public docs have been removed, and previously-optional columns are now marked Required to match the schema's validation rules. The most visible changes:

Pipelines preparing data against the previous documentation may need their column names and required-field coverage reconciled with the updated pages.

The Commercial Pricing page now records the recommended operationType (APPEND or UPSERT) for each resource. For Commercial Pricing, most tables use APPEND because the solution uses the historical state of customers, products, prices, and merchants as model features. quote_line and sale use UPSERT, since re-submissions of the same business key are corrections rather than new versions.

The Competitor prices dataset is now documented in the user guide. The dataset was already part of the API; it just didn't have a customer-facing data-requirements page until now.

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.

The Python reference script in the historical-data-ingestion guide:

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).

The quantity field on Quote line and Sale has been corrected from integer to float in both the API Guide and the User Guide dataset pages. The schema has always accepted decimals here; the doc was wrong. Pipelines that were rounding to integer-typed values should switch to sending the value as a number (decimal or whole) without coercion.

Every per-table page in the API Guide and the corresponding dataset pages in the User Guide now include a Nullable column next to the existing Required column. The two flags are independent:

This makes it possible to distinguish "I must send the key but the value can be null" from "I must send a non-null value" at a glance per column. See Schema definition structure for the underlying validation rules.

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. It 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, so customers can match the failure in their integration logs.