← FlowPatch

FREE SELF-ASSESSMENT

Seven questions before trusting an API automation.

Choose one external provider boundary. Check a statement only if the control exists today and is covered by a failure-path test.

Runs entirely in your browser. Your answers are not transmitted or stored.

1. A stable operation ID exists before the first network call.

Every retry uses the same business identity or provider idempotency key—not a new timestamp or attempt ID.

2. A timeout is treated as “outcome unknown,” not automatically “failed.”

The system reconciles whether the provider accepted work before sending another create or charge request.

3. Retry rules are explicit and bounded.

Only documented transient failures retry; backoff has jitter and a time/attempt budget; Retry-After is honored.

4. Webhook authenticity and replay are handled.

Signatures are verified against the raw body, replay windows are enforced where supported, and delivery IDs are durably deduplicated.

5. Polling and webhooks use the same idempotent finalization path.

Two concurrent completion signals cannot publish, bill, credit, notify, or write the final asset twice.

6. State transitions are monotonic and crash-safe.

A late “running” event cannot overwrite success, and a crash between accepting an event and dispatching work cannot silently drop it.

7. Reconciliation detects stranded operations.

A scheduled process finds accepted-but-unfinished work, unmatched webhooks, expired leases, and local/provider state disagreements.

0/7 controls confirmed

High risk: the boundary depends on happy-path behavior.

How to interpret the score

0–2 · High risk

Duplicate side effects or lost work are plausible under ordinary timeouts and retries.

3–5 · Needs controls

The design has useful safeguards but still contains an unowned failure path.

6–7 · Better prepared

Verify each checked control with concurrent, timeout, replay, and crash-recovery tests.