POST. There is no Batch Relay wrapper around the CloudEvent.
Configure destinations and select available topics in the
Developer Dashboard. The dashboard also
shows delivery history and any topic references available to your account.
Contract authority
The live AsyncAPI document is the canonical public event contract:/specs/events-v1.asyncapi.json, but an
integration should retrieve or pin the live canonical document for release
validation.
Direct CloudEvent payload
Every request hasContent-Type: application/cloudevents+json and a JSON body
like this:
data carries the
topic-specific business fact. origin identifies how the fact entered Batch
Relay (storefront, developer_api, or system); it is not a transport
channel.
When an event defines monetary summary fields, all five components are present:
subtotal_minor_units, discount_minor_units, shipping_minor_units,
tax_minor_units, and total_minor_units. Values are non-negative integers in
USD; an inapplicable component is 0, not omitted.
Delivery semantics
- Delivery is asynchronous and at least once. A receiver can see the same CloudEvent more than once.
- A
2xxresponse acknowledges the delivery. Any other response, timeout, or network failure is eligible for retry. - Retry timing and delivery history are available in the Developer Dashboard; do not rely on an assumed retry schedule.
- Events may arrive out of order. Use
time,resourceversion, and your own durable state rules rather than arrival order. - One HTTP request contains one CloudEvent. Batch delivery is not part of V1.
Public event catalog
This public reference intentionally lists only public topics. Topics that need additional account capabilities are documented only in the authenticated Developer Dashboard, and operator-only topics do not appear in customer-facing documentation. See the topic reference and complete examples.Forms, event media, and import attempts
Form definitions describe the questions a Studio collects.form.created.v1,
form.updated.v1, and form_revision.published.v1 describe authoring and
publication. Form response topics describe a committed submission or edit to
answers. Their actor and submission method identify whether a guardian, staff
member, or API performed the operation. They do not identify the purchaser or
include answer values. There are no form archive, delete, or restore topics.
event.updated.v1 reports safe event metadata changes.
photo_assignment.updated.v1 reports changes to portrait or team-photo
assignment using opaque resource references. They contain no child names,
contact details, image URLs, or form answers.
Image import completion means the intended media assignment was committed.
An upload alone is not completion. A failed attempt records its stage, such as
upload or commit, and its retryable flag. A retryable failure can be followed
by a successful committed completion. Treat each event as a lifecycle fact,
not a final judgment on the whole import session.
These topics require the matching account capability and destination
subscription. Their schemas and examples are available in the authenticated
Developer Dashboard.
Fulfillment progress and completion
order.fulfillment_updated.v1 reports changes to the digital, lab, and Studio
fulfillment components. Consumers can track a mixed order without treating the
first successful component as completion of the entire order.
order.fulfilled.v1 means every required component finished successfully.
Digital completion requires successful delivery to the customer. Preparing a
file or sending a debug preview does not qualify. Lab completion requires the
recorded shipment milestone. Studio completion requires the recorded handoff
or shipment milestone. Shipment and handoff are not proof of arrival at the
customer’s address. A digital-only order completes after successful digital
delivery; a mixed order also waits for its required physical components.
Purchaser context
Core storefront order events may carry an opaquebuyer_ref. The purchaser
is separate from actorkind, which can be system for payment confirmation.
A guest reference is scoped to that transaction. An account reference is scoped
to the Studio and does not expose a guardian or authentication identifier.
Names and email addresses are retrieved through a separately authorized API
request. They are never added to the universal event payload. See
Purchaser context for explicit Studio opt-in,
API key permissions, and guest handling.