Skip to main content
Start background work on an explicit selection of products, then use its task_id to track progress. A 202 Accepted response means the job was accepted; it does not mean processing has finished.

​
Choose an action

Existing keys do not gain action permissions automatically. Create a replacement with the scopes you need, including jobs:read if your integration monitors results.

​
Enrich product content

All three launch endpoints accept 1–1,000 distinct product_ids. Replace the example IDs with products in your project. If any selected product is unavailable, the entire launch is rejected.
enrich_type accepts description, short_description, titles, seo_meta, product_attributes, internal_linking, search_intent and image_alt_text. Set an optional prompt_id to use an accessible prompt in the same project. Existing content is preserved by default (fill_empty_only: true). Set it to false only when you intend to regenerate populated content. Eligibility, current field and attribute permissions, prompt access and credit availability are checked before launch. max_credits bounds the estimate accepted at launch; it does not guarantee that every selected field will change. The response includes task_id, status, total_items, estimated_credits and deduplicated. Save the task ID and poll its job endpoint.

​
Translate selected fields

Select 1–25 distinct target locales and 1–8 distinct fields: name, name_long, description, short_description, meta_title, meta_description, meta_keywords or faqs. Optional settings include translation_instructions, high_quality, force_retranslate and max_credits. Unsupported locales reject the whole request; none are silently discarded.

​
Apply bulk changes

Bulk actions cover text cleanup, prices, stock, dimensions, shipping, categories, attributes, unit conversion, visibility, status and quality recalculation. The endpoint schema lists the accepted action names. action_config depends on the action; the bulk-editing guides explain each operation’s settings. Invalid configurations are rejected before a job is created. Bulk-edit permissions and the relevant field permissions still apply.

​
Monitor and cancel

Read status, stage, progress_percentage, total_items, processed_items, successful_items, failed_items and skipped_items, together with timestamps and cancellation_requested. Check the counters as well as the status, then read the affected products to confirm their resulting content. Job responses expose progress without internal worker payloads or credentials.
Cancellation is cooperative: monitor the job after requesting it. Work already applied is not rolled back. A finished job without a previous cancellation request can return 409.

​
Retry without launching duplicate work

Send one Idempotency-Key per logical launch and reuse it for retries with the same method, path, query and body. Replays return the original response, including its task ID. Use a new key for a new run. Poll GET /jobs/{task_id} for fresh progress instead of replaying the launch. Follow Retry-After on 429 responses and the shared retry contract.