AI ecommerce automation with review gates

Automate the handoff, not just the prompt

A repeatable content workflow needs to answer which product changed, which source revision was used, what work remains and who may publish it. A scheduled prompt with a CSV attachment cannot answer those questions by itself. Treat the prompt as one step in a job whose state is stored outside the conversation.

Start with exportable content and an offline review queue. Give each job a durable record and an explicit next action. Keep live product updates disabled until the destination adapter and approval checks have been exercised in a controlled store. This lets you build generation and review before adding publication permissions.

Give each job a stable identity

Use the source revision, product identifier, locale, glossary revision and prompt revision to identify the intended work. A retry of the same job should not create an unrelated candidate or apply the same import twice. A change to the source or rules should create new work with a visible relationship to the older candidate.

Do not key jobs by row number: sorting an export changes row positions. Keep prices and units in the source snapshot, but permit generated output only for approved text fields. The following record is an illustrative application contract to adapt for your job store.

{
  "productId": "SYNTHETIC-CATALOG-A",
  "locale": "de",
  "sourceRevision": "source-revision-required",
  "glossaryRevision": "glossary-revision-required",
  "promptRevision": "prompt-revision-required",
  "state": "queued",
  "approval": null,
  "importReceipt": null
}

Persist observable state transitions

Store candidate output before advancing to validation. Store validation issues before assigning a reviewer. Bind an approval to the exact candidate and source revisions. The publisher should refuse records whose content changed after approval, even if an earlier version was accepted.

Use a hold state for ambiguous outcomes. For example, a connection loss during an import does not prove the store rejected the write. Reconcile the current stored fields before retrying. Implement the following proposed states in your orchestration layer, with transition checks next to the operation that persists each result.

Separate the model client from the store adapter

Give the drafting worker only the approved source subset and model credentials. Put store credentials in a separate adapter with a narrow operation, such as preparing a description patch. An AI request completing successfully should not be able to publish a product as a side effect.

Shopify's documented translation path uses resource-specific content and digests; WooCommerce documents a product CSV importer. Give each interface its own mapper and verification step. Configure model credentials in the drafting client, and keep source reads and authorized store writes in the destination adapter. Test these boundaries independently before joining the flow.

Bound retries and isolate bad records

Retry temporary transport failures with a finite policy and recorded attempts. Repeating a structurally invalid response without changing the cause can waste both usage and reviewer time. Keep failure categories distinct: authentication, unavailable model, incomplete generation, invalid fields and rejected content need different interventions.

Allow successful records to remain available while holding failed ones. Preserve all attempts for the affected product, including candidates that failed validation. A worker restart should resume from persisted state, not regenerate the entire catalog. Test cancellation too: stopping generation must not silently leave an import process running.

Measure accepted work and its full cost

Associate usage records with the job and attempt, including failed requests when billing evidence exists. Track drafting, review and revision calls separately. Preserve missing usage as unknown; a missing receipt is not a free request. Keep editor time separate from the API ledger rather than blending unlike measurements into one number.

Define accepted work by your release criteria, such as an approved product-locale revision. Divide recorded costs by accepted work only when the denominator is nonzero and the sample is clearly scoped. Use current provider or gateway billing information, and retain the date and billing source with the report.

Reconcile imports and prepare reversal

Create an import proposal containing only approved changes, and save the previous values for those fields. Compare the source revision again immediately before an authorized write. If another editor has changed the product, pause and ask for a new review instead of overwriting their work.

After import, read back the intended fields and classify mismatches by product and locale. A reversal should restore only this batch's changes when the store still matches the imported revision; otherwise it needs a conflict review. Keep import permissions independent from the permission to generate text.

Verify a small failure-inclusive flow

Use synthetic products to test one accepted candidate, one protected-field violation and one changed-source conflict. Restart the worker between drafting and approval. Check that approved work survives and that held work cannot enter an import proposal. These checks exercise the state contract more directly than repeatedly testing prompt wording.

Then test the adapter in a staging store with explicit permission. Retain the source snapshot, generated revision, approval, import receipt and read-back comparison. A local job simulation establishes orchestration behavior only; it cannot establish model quality or a successful store integration.

FAQ