Developer preview

A proposed API for products, inventory, and orders.

This page describes the API contract being designed with our design partners. Everything here is a proposal: names, fields, and behaviour may change before anything is released.

Availability today

Public API: Not available
Sandbox: Not available
API keys: Not issued
API contract: In design with partners
Documentation: This preview

01. Intended scope

Three resources, one contract.

The first version is intended to cover product records, inventory levels and adjustments, and orders. Payments, shipping, tax, and storefront rendering are outside the initial scope.

Proposed endpoints
Method	Endpoint	Purpose
POST	`/v1/products`Create a product and its variants	Create a product and its variants
GET	`/v1/products/{id}`Retrieve a product	Retrieve a product
PATCH	`/v1/products/{id}`Update product fields or attributes	Update product fields or attributes
GET	`/v1/inventory/{sku}`Read the inventory level for a SKU	Read the inventory level for a SKU
POST	`/v1/inventory/adjustments`Record a signed stock adjustment	Record a signed stock adjustment
POST	`/v1/orders`Create an order from line items	Create an order from line items
GET	`/v1/orders/{id}`Retrieve an order and its status	Retrieve an order and its status

Browse the full API reference

02. Proposed resource models

One clear shape for each resource.

Product

/v1/products

A catalog record with one or more sellable variants identified by SKU.

id: stringStable identifier, e.g. prd_…
name: stringDisplay name
status: 'draft' | 'active' | 'archived'Catalog visibility
attributes: Record<string, string>Structured, project-defined attributes
variants[]: VariantSKU, variant attributes, and price in minor units

Inventory level

/v1/inventory

Stock state for a SKU, kept separate from product data and changed through adjustments.

sku: stringThe variant this level belongs to
on_hand: integerUnits physically counted
available: integerUnits that can be ordered
adjustments[]: AdjustmentSigned delta, reason, and timestamp

Order

/v1/orders

A structured record of what was ordered, with its own lifecycle status.

id: stringStable identifier, e.g. ord_…
status: 'pending' | 'confirmed' | 'fulfilled' | 'cancelled'Order lifecycle, kept separate from payment
line_items[]: LineItemSKU, quantity, and unit price
subtotal: integerSum of line items in minor units
currency: stringISO 4217 code

03. Example requests

What an integration could look like.

Illustrative requests and responses for the proposed contract. They have not been run against a live API; api.condense.example is a reserved placeholder host.

Authentication Planned: Bearer API keys scoped to a single project. Keys will be issued per environment once access opens.
Errors Planned: Consistent JSON error objects with a type, a machine-readable code, a message, and the offending parameter.
Money Planned: Amounts in integer minor units with an explicit ISO 4217 currency, to avoid floating-point drift.
Versioning Planned: A versioned path prefix (/v1) so integrations are not broken by later changes.
Idempotency In design: Safe retries for create requests are being evaluated with design partners.
Pagination and filtering In design: List endpoint conventions are being evaluated with design partners.

Proposed API, illustrative

POST /v1/products

curl -X POST https://api.condense.example/v1/products \
  -H "Authorization: Bearer $CONDENSE_API_KEY" \
  --data-urlencode "name=Organic Cotton Tee" \
  --data-urlencode "sku=TEE-ORG-BLK-M" \
  --data-urlencode "price[amount]=2400" \
  --data-urlencode "price[currency]=EUR"1curl -X POST https://api.condense.example/v1/products \2  -H "Authorization: Bearer $CONDENSE_API_KEY" \3  --data-urlencode "name=Organic Cotton Tee" \4  --data-urlencode "sku=TEE-ORG-BLK-M" \5  --data-urlencode "price[amount]=2400" \6  --data-urlencode "price[currency]=EUR"

04. Expected integration workflow

From first request to a working flow.

The intended path for design partners, covered in more detail in the integration process.

01Define the project and its commerce data requirements.
02Connect the integration with project-scoped credentials, once access is available.
03Validate product creation, stock adjustments, order creation, and failure cases.
04Reuse the validated integration as a starting point for suitable future projects.

Want early access when it exists?

Access opens to design partners first. Apply to review the contract now and test integrations as functionality becomes available.

Become a design partner

Method

Endpoint

POST

/v1/productsCreate a product and its variants

GET

/v1/products/{id}Retrieve a product

PATCH

/v1/products/{id}Update product fields or attributes

GET

/v1/inventory/{sku}Read the inventory level for a SKU

POST

/v1/inventory/adjustmentsRecord a signed stock adjustment

POST

/v1/ordersCreate an order from line items

GET

/v1/orders/{id}Retrieve an order and its status

Your privacy matters.

A proposed API for products, inventory, and orders.

Three resources, one contract.

One clear shape for each resource.

Product

Inventory level

Order

What an integration could look like.

From first request to a working flow.

Want early access when it exists?

A proposed API for products, inventory, and orders.

Three resources, one contract.

One clear shape for each resource.

Product

Inventory level

Order

What an integration could look like.

From first request to a working flow.

Want early access when it exists?