An assistant asks a booking service to create an appointment. The network connection drops before the response arrives. Should it retry?
The dangerous assumption is that no response means no booking. The service may have saved the appointment before the connection failed. A second create request can then produce a duplicate.
This is a design walkthrough, not a report of measured customer results. The examples below illustrate a pattern; the exact guarantees depend on the service you integrate.
Separate intent from attempts
Treat "book this appointment" as one operation with a durable identity. Individual HTTP requests are attempts to complete that operation, not new user instructions.
Before the first write, record the approved details, the target service and an operation identifier. Do not put private customer details into the identifier. If the request times out, keep the operation unresolved rather than marking it failed or completed.
A useful state model is:
- Prepared: the request is validated and permitted.
- Submitted: a write has been attempted.
- Confirmed: the target service shows the intended result.
- Uncertain: the request's outcome could not be established.
- Escalated: a person needs to decide the next step.
These labels are a proposed design, not an API standard. The important distinction is between a confirmed failure and an unknown outcome.
Use the provider's duplicate protection
Google Calendar's create-events guide explains that a client can supply an event ID in the required format. The guide explicitly describes preventing duplicate creation when an operation fails after succeeding in Calendar's backend.
That is more useful than inventing a new random event ID on every retry. Keep the identifier associated with the original intent, then reconcile against the target calendar. Validate the date, time zone, participants and current availability separately. Duplicate protection does not prove that those details were right.
Stripe provides a different example. Its idempotent-requests documentation describes an idempotency key for retrying supported requests. For API v1, it returns the saved response for a reused key after endpoint execution begins, including saved errors. The documented retention and parameter checks matter: this is not a promise that any request can be replayed forever.
Do not copy payment API assumptions into a calendar integration. Read each provider's current contract and test the failure cases it actually supports.
Reconcile before claiming success
After an uncertain write, use a supported read path to inspect the relevant resource. Match the operation identifier and the meaningful fields, not only a similar title.
If the resource exists with the approved details, record the provider's identifier and report the confirmed state. If it does not appear, follow the provider's documented retry behavior. If the read is unavailable or ambiguous, preserve the uncertainty and hand it to a person rather than quietly creating a second object.
A calendar entry is also not proof of every downstream effect. Invitations, notifications and external booking systems may have their own delivery states. Tell the user what was verified, not what you hope followed from it.
Test the awkward path
Include these scenarios in an integration test plan:
- The provider saves the resource but the response is lost.
- A duplicate request arrives while the first is still running.
- A retry has changed parameters.
- The resource exists, but a later read is temporarily unavailable.
- The same person makes a genuinely new request with similar details.
- The provider rejects the request before execution begins.
The final case matters because a rejected request is different from one that ran and returned an error. Your retry policy should follow the provider's semantics, not a single catch-all exception handler.
Permission still comes first
A reliable retry mechanism cannot grant authority to make the original booking. Confirm the requested action, its audience and any costs before writing. Keep the ability to suggest separate from permission to execute.
The broader business principle is to measure the complete process, including verification, review and recovery. IT Impress's AI productivity and business-value guide discusses that approach. Disclosure: I am the founder of IT Impress.
For an action-taking assistant, a useful result is not merely "the request was sent." It is a result that can be checked, explained and recovered without making the user discover the uncertainty later.
Top comments (0)