AI Prompts for API Design: When the Same Request Arrives Twice

Every endpoint an AI writes assumes the request arrives once. These AI prompts for API design put the guard where a refresh cannot reach it: one key, one row, one test that fails without it.

The Click That Happens Twice

The generated code says nothing about a second arrival. Not the button, not the handler, not the table. You asked for a checkout that saves the order and charges the card, and that is what came back, written for one request that arrives once. A courier handed a letter once delivers it once; hand the same letter to one with no job number and no ledger, and the second handoff looks like a new job. That describes what the prompt asked for, not how a model thinks: a prompt describes a case, and repetition is a case nobody wrote down.

Four Ways One Click Becomes Two

The first is the finger that taps twice because the button did not answer. The second is the refresh after a timeout, when the browser offers to resend the same POST. The third is an automatic retry by the client, where the request succeeded and only the response was lost. The fourth is a second tab, or the back button followed by a fresh submit. Only the first happens in front of your eyes; the other three look like one click in every log.

What the Model Writes, and What It Leaves Out

What comes back is the visible half: the route, the form, the handler that creates the record, a success message. What is missing is what you would only notice on the second arrival. No field identifies the operation, nothing is checked before the write, the table carries no rule.

The Disabled Button Is Not a Guard

Disabling a button on click happens in the browser. It disappears on refresh, does not stop a second tab, and never runs if JavaScript fails.

What HTTP Already Decided

The specification settled part of this. A method is idempotent when repeating an identical request has the same intended effect as sending it once. PUT, DELETE and the safe methods land on the safe side; POST does not, so a form submission and a charge are exactly the case the specification does not protect. It names the risk: some clients retry a non-idempotent request when the connection closes before any response arrives. See RFC 9110, section 9.2.2.

The Three Places a Guard Can Live

Three layers, not interchangeable: one in the request, one in the application, one in the database.

Layer	What it stops	What it cannot stop
A key sent by the client	Repeats of one operation, if the server reads it	Anything alone: a label until something checks it
A record checked before the write	The second write; it can replay the first response	Two processes reading and writing at the same instant
A unique constraint in the table	The second row, even under concurrency	Nothing, but it arrives as a database error to translate

The hierarchy in one sentence: the first layer is an intention, the second a decision, the third the last word. Only the third survives two workers writing at the same millisecond, which is why a guard living only in application code has a window.

Prompt 1 - AI Prompts for API Design: The Endpoint That Accepts a Key

What the Prompt Returns

REST API Design System takes a product description and returns seven blocks: a resource map separating nested from top-level resources, endpoints with method, path and the shape of request and response, status codes for success and every error, auth with rate limiting, pagination conventions, versioning, and an OpenAPI 3.0 fragment.

The Field That Is Not There

None of those blocks answers what happens when the same request arrives again. Add a write contract of your own with four answers: which key travels in the header, what the server returns when the key repeats (the original response, not an error), which status code the conflict uses, and how the key expires. The client generates the key and reuses it on every retry, the pattern in an IETF Internet-Draft on the idempotency key header. It is a draft in IESG evaluation, not a published standard, and the mechanism holds either way.

The Check, Outside the Chat

Send the same request twice with the same key: same resource id, same body, one row. Then change the key, where a second row is correct. If that one is refused too, the guard is blocking legitimate work.

Prompt 2 - The Feature With a Unique Index and a Test

What the Prompt Returns

Laravel Feature Builder builds a feature in seven ordered blocks: migration with indexes and foreign keys, model with casts and relations, validation in a form request, a minimal controller, views, Pest tests for success, validation failure and authorization, plus a security block.

Where the Guard Goes

Two blocks to steer. In the migration, ask for a unique index on the operation key, or on the columns that cannot repeat. In the tests, ask for the case nobody writes: the same request submitted twice, asserting one row. A unique validation rule alone is not enough, because between the check and the insert two simultaneous requests both pass; the constraint closes it. See the validation documentation.

The Check, Outside the Chat

Run the test twice, delete the unique index, run it again. It must fail without the guard. A test that stays green is testing the mock, not the write.

Prompt 3 - The WordPress Form That Cannot Post Twice

What the Prompt Returns

PHP and WordPress Developer returns the code with a namespace, a map of the hooks it registers and why, a security block with sanitizing and output escaping, a performance block on transients, asset loading and a WP-CLI snippet.

A Nonce Is Not a Duplicate Guard

The nonce covers requests from somewhere else, and it can be reused while valid, so it does not count submissions. Here the guard is a unique key in the database, one meta entry per operation, or a transient written before the work starts and read on the way in.

The Check, Outside the Chat

Submit the form twice with the same nonce and count rows. Repeat with JavaScript disabled, the case the disabled button never covers.

The Five-Minute Check, Outside the Chat

Five checks, none needs a test suite.

Check	What you do	What proves it works
1	The same POST twice with the same key	Same id, same body, one row
2	Two tabs at the same moment	One row, not almost always one
3	Cut the response, then retry	No second row, same success message
4	Remove the unique constraint and rerun	The test fails
5	Read the message on the retry	It says the operation succeeded, so nobody clicks again

The fifth is the cheapest and the one most often missed. A retry that reports an error sends the user back to the button, and the next click creates the duplicate the guard prevented.

Where This Still Fails

Nothing here gives you exactly once from end to end. The guard covers your write, not the write of the third party you call afterwards: the email, the charge, the webhook. The key has to expire, or the table grows without bound. And a guard placed too high blocks legitimate work, because two identical orders from one customer are two orders.

FAQ

Do I need this if my button is disabled on click? Yes. It disappears on refresh and covers neither two tabs nor an automatic retry.

Is the idempotency key a standard? Not yet. It is a pattern defined in an IETF Internet-Draft and used in production by many APIs.

Does a unique validation rule solve it? Not alone. Between validating and inserting there is a window two simultaneous requests slip through, and the constraint decides.

Which prompt do I run first? The first if the API is still on paper, the second if only the guard is missing, the third if the form lives in WordPress.

The Second Arrival Is the Case Nobody Asked For

A request gets written once, and the second arrival is the case the prompt never described. The fix is not a longer prompt: it is a key that travels with the request, a record the server checks, a constraint with the last word, and a test run twice. Start with the API design prompt if the contract is still on paper, or with the feature builder if you only need the index and the test. Then break it on purpose: remove the constraint, watch the test go red, put it back.