Creates a new entity, or fully replaces the stored row for an existing key (a full-row upsert): omitted optional fields are reset, not preserved. Use PUT when you need to retain fields you are not changing.

Batch rules

• The body is a JSON array of 1–500 records. The limit is a record count, not a byte-size guarantee — split earlier when records carry large translation or extra objects.
• Entities must be sent in order of hierarchy: Category → Class → Type → Event → Market → Selection, parents before children.
• Each HTTP method applies one action to the whole array — do not mix create, update, and delete in one request.
• Do not include the same entity type and key more than once in a batch; the first occurrence wins.

Record expiry — the optional X-Expires-After header (integer seconds, minimum 60, at most 2147483647) applies the same relative expiry to every record in the request. POST without the header creates or replaces the row without an expiry — clearing any existing expiry as part of the full-row replacement. Expiry is evaluated asynchronously and is not an exact client-side scheduler.

Retries — there is no client-supplied idempotency key. A repeated POST converges to the full row in the retried request, potentially overwriting a newer change. Ordering is not guaranteed across concurrent requests, so serialise dependent writes.