Give the article a stable identity
Use an article identifier that survives title changes. Keep the revision alongside it. The destination should be explicit, especially when one publishing service handles several independent sites. A useful receipt contains the site, article, revision, destination URL and result. Those are proposed acceptance criteria, not evidence that any particular platform supports them.
Check before creating a side effect
Make missing titles, malformed links and absent images visible before the publish action. Separate validation failures from temporary delivery failures: the first needs corrected input; the second may be retryable. Define a duplicate-request policy using the actual destination API. Where an endpoint documents idempotency, understand its scope and retention period rather than assuming the behavior is universal.
Inspect the page, not just the response
Fetch the resulting URL and check the fields that matter to the article: heading, canonical, images and key links. A successful HTTP response can coexist with an incorrect render or the wrong revision. If verification fails, retain the receipt and route the issue to a named owner. Avoid repeatedly creating new posts while trying to discover what happened to the first request.
MDN: HTTP 202 Accepted ↗ — Accepted means processing is not complete. The endpoint must define how its eventual result can be checked.
Retain an exit path
Store your own content and asset records outside the workflow configuration. When a publication changes owner or platform, it should be possible to export its articles, mappings and receipts without exporting sibling-site credentials. This is an ownership requirement to put into the evaluation brief.
Record the plan, version, date, input set, output, failure behavior and billing units. A workflow diagram is a design pattern, not a benchmark.
