Product configurations
Try a configuration
Exactly the body creation takes, run through exactly its checks, and nothing written. See the refusal — or the values as they will read back — before a configuration that can never be removed exists.
POST
A configuration is immutable and cannot be removed, so a mistaken one stands in your catalogue forever. This route takes the creation body byte for byte, runs every check creation runs in the same order, and stores nothing. A body creation would store answers
No
200 with the Archetype, the values as creation would read them back, and id — the identifier creation would compose. Asking does not reserve it: two previews answer the same identifier and the create that follows takes it. A body creation would refuse meets creation’s own refusal: the same status, the same code, the same field named.
No idempotency key is read: there is nothing to replay. A form that previews under the key it will submit under loses nothing by it.
Path parameters
string
required
The Tenancy that would hold the configuration.
Body
The creation body:archetype and values. Stating id is refused here exactly as it is there.
Response
string
required
The identifier the create would compose, so you can show it before the Product exists. Not reserved by asking.
string
required
As sent.
object
required
The terms as creation would read them back — a rate in its exact form, one schedule under
schedule and a menu under schedules.object
required
The value every field the frame declares would take, stated or by default — as creation answers it.
object[]
required
What creation would advise for the same body — the same codes, empty where there is nothing. Nothing is refused for them.
id, no version, no created_at: a preview knows none of them.