Write outcomes & verification
Distinguish previews, accepted writes and completed work, and reconcile uncertain outcomes before retrying.
For automations that publish content or send messages, persist each successful step and treat uncertain outcomes separately from confirmed failures.
What a check proves
| Evidence | What it proves | What it does not prove |
|---|---|---|
| Source or client inspection | Observed payload construction or handling | Live acceptance for an account |
| Authenticated read | Resource access at that time | Permission to write |
| Recipient preview | A target/count under those filters | Attachment validity or delivery |
| Successful create response | Acceptance/creation according to that endpoint | Completion for every recipient |
| Read-back of returned ID | The resource exists with the observed state | Completion of unrelated downstream steps |
| Controlled live workflow | The tested account and payload completed the observed steps | Universal success for other accounts or future attempts |
Verification notes should state the date, method, platform/account scope and remaining uncertainty. A statically discovered endpoint is not live verified merely because it appears in an OpenAPI schema.
Before writing
Check documented account capabilities and write permission, then confirm target,
price, attachment ownership and readiness. Use a documented preview if one
exists. Do not invent a dry_run field: unsupported fields can be ignored while
the write executes. Do not turn writes on automatically to make a preview pass.
The native message recipient preview is a GET; the CRM mass helper has its own
JSON boolean dry_run. See Messaging & mass DM.
Persist outcomes, not just HTTP success
Store the account, business-operation key, intended request, attempt time, returned resource ID and observed outcome. Use a database uniqueness constraint and an atomic worker claim to stop duplicate local jobs.
Persist success before advancing to dependent work. A successful Feed remains successful if its follow-up message fails. Resume from the saved post ID rather than repeating the whole workflow.
HTTP 200 can contain partial failures. Inspect documented per-item results.
Passthrough responses wrap the upstream body in data, whose shape may be an
array or object; do not assume every endpoint returns data.list.
Unknown is a separate outcome
A timeout, connection loss or 5xx after submission may occur after the platform commits a write. A worker crash after sending but before storing the response creates the same uncertainty.
Disable blind retries for non-idempotent POSTs in clients and job runners. Mark
uncertain attempts outcome_unknown and reconcile through a documented resource
or status read. An empty pending queue or a missing item on one page is not proof
that the operation failed.
Retry automatically only when the endpoint documents safe idempotency, or the
outcome is conclusive and the specific failure is safe to retry. An arbitrary
Idempotency-Key header does not create support. An upload receipt or local
unique job does not automatically protect a later post or message send.
If no authoritative read resolves the outcome, hold it for review. Do not promise exactly-once external effects without a verified end-to-end idempotency contract.