Duplicate Vendor Orders After a Retry? Design an Idempotent PO Intake Workflow

Short answer: Duplicate purchase orders happen when your system treats a retried delivery of the same PO as a new order. The fix is an idempotent PO intake workflow. Every incoming PO gets a stable key (vendor code + PO number + revision). That key is written to a database with a unique constraint *before* anything else happens. A retry then finds the existing record and returns the earlier result instead of creating a second order.

If you run Amazon Vendor Central (1P) in the US, UK or EU, you've probably seen this at least once. One PO becomes two sales orders in your ERP. The warehouse picks twice. Finance asks why the numbers don't match. Everyone blames the retry, but the retry isn't the real problem. The intake design is.

This guide is written for vendor operations and integration leads. It covers why duplicates happen, how to build the key, and what the full workflow looks like. For more help with the Vendor side of Amazon, start at Growithamazon.com.

Table of Contents

• ●Why Do Duplicate Purchase Orders Happen After a Retry?

• ●What Does "Idempotent" Actually Mean Here?

• ●How Do You Build the Idempotency Key for an Amazon PO?

• ●The Idempotent PO Intake Workflow, Step by Step

• ●A Worked Example (Illustrative)

• ●Does This Apply to Direct Fulfillment?

• ●Common Mistakes in PO Intake Design

• ●What to Monitor Once It's Live

• ●Pre-Launch Checklist

• ●Wrapping Up

• ●Frequently Asked Questions

Why Do Duplicate Purchase Orders Happen After a Retry?

Retries are a good thing. Networks drop, APIs time out, middleware restarts. A system that never retries loses orders. The trouble starts when a retry is *safe for delivery* but *unsafe for processing*.

Here's the usual story. Your integration pulls a PO and asks the ERP to create the order. The ERP is slow, so your integration times out and retries. The first request had actually succeeded. Now you have two orders.

The fourth row matters most. Duplicates aren't a bug in your queue. They're a normal condition your workflow has to handle.

What Does "Idempotent" Actually Mean Here?

An operation is idempotent when doing it once or ten times leaves the system in the same state. For PO intake, receiving the same PO ten times still produces exactly one order.

The idea is well established in API design. Stripe documents that it saves the status code and body of the first request for a given idempotency key, then returns that same result for later requests with the same key (Stripe's idempotent requests documentation). There's also an IETF working draft for a standard Idempotency-Key header. It's still a draft, not a finished standard, but it's a useful reference for edge cases like in-flight requests and key reuse (IETF draft).

You're applying the same idea on the receiving side. Amazon is the sender and you can't change how it sends, so the key has to come from the PO itself.

How Do You Build the Idempotency Key for an Amazon PO?

This is the part people get wrong. A PO number alone is not enough, because Amazon can change a PO after it's placed. That change is a legitimate update, not a duplicate.

The Vendor Orders API makes this explicit. It has a filter for purchase orders modified after they were placed, and vendors are expected to pull the changed PO and fulfil the updated version, not the original (Vendor Orders API reference). If your key ignores revisions, you'll either drop real changes or work from stale data.

A solid key has three parts.

Part 1: Vendor Code

The ordering vendor code on the PO. This matters if you run multiple codes or regions.

Part 2: PO Number

The purchase order number as Amazon sends it.

Part 3: Revision Marker

Original versus changed version. How you read the revision depends on your connection. On the API, use the changed-PO indicator and the PO state. On EDI, check how your integration flags a replacement or change. In X12 that's usually the transaction purpose code in the 850. Confirm the exact behaviour in your own Vendor Central setup, since it can vary by integration.

Add a Payload Hash

Then add one more field: a payload hash of the normalised PO content. You don't use it as the key. You use it to answer one question: "Is this the same PO, or the same key with different contents?"

Using EDIFACT in the UK or EU?

The logic doesn't change. The purchase order arrives as ORDERS instead of an 850, and the acknowledgement goes back as ORDRSP instead of an 855. Build the same key, claim it atomically, and process once. Check which message set your Vendor Central setup actually uses. One more point: an EDI interchange control number can help you spot a re-sent file, but a resend may arrive with a new control number, so it shouldn't replace your business-level key.

The Idempotent PO Intake Workflow, Step by Step

This design holds up under retries, restarts and manual re-imports.

Step 1: Persist the Raw PO First

Before you parse, validate or transform anything, store the raw payload exactly as received. This is your audit trail and your safety net. If something breaks later, you replay from here instead of asking Amazon to resend.

Step 2: Compute the Intake Key and Claim It Atomically

Insert a row keyed on vendor code + PO number + revision, with a unique constraint on that key. The database, not your application code, decides who wins a race. Two workers handling the same PO at the same moment can't both succeed.

```sql CREATE TABLE po_intake ( intake_key TEXT PRIMARY KEY, -- vendor_code|po_number|revision payload_hash TEXT NOT NULL, status TEXT NOT NULL, -- RECEIVED, ORDER_CREATED, ACKNOWLEDGED, FAILED erp_order_ref TEXT, ack_txn_id TEXT, first_seen_at TIMESTAMPTZ DEFAULT now(), updated_at TIMESTAMPTZ DEFAULT now() );

INSERT INTO po_intake (intake_key, payload_hash, status) VALUES ($1, $2, 'RECEIVED') ON CONFLICT (intake_key) DO NOTHING; ```

If the insert returns a row, you own this PO. If it returns nothing, someone already has it. Go to step 3.

Step 3: Decide What a Conflict Means

When the key already exists, there are three possibilities.

The IETF draft treats these cases the same way in spirit: a conflict response for a request still in flight, and a client error when a key is reused with a different payload.

Step 4: Look Up Before You Create, Then Create With the Same Key

Pass your intake key into the ERP as the external or customer reference, and enforce uniqueness there too. Before creating an order, check whether the ERP already holds one with that reference. Now even if your intake table somehow failed, the ERP refuses the duplicate. Two locks are better than one.

Step 5: Acknowledge Receipt, Then Acknowledge the PO, Exactly Once

On EDI, one platform's Amazon Vendor workflow guide describes exporting a functional acknowledgement for the PO right away, before you review it and send the order acknowledgement (Cin7 Omni EDI workflow for Amazon Vendor). Transport-level acknowledgement and business-level acknowledgement are separate steps, so track them separately.

For the PO itself, Amazon expects an acknowledgement for each one. In EDI that's the 855. On the API, it's the acknowledgement operation in the Vendor Orders API, and the Vendor Transaction Status API lets you check what happened to what you submitted (Vendor retail procurement APIs use case guide). Store the transaction ID against the intake row. If your ack call times out, check the status first. Resending blindly is how you create the next duplicate.

Remember that Amazon wants every PO line item covered in the acknowledgement, so build that into your validation and a partial ack never goes out.

Timing matters too. One integration provider's guide lists a 48-hour window for the 855 after the 850 (Base.com guide to EDI and API for Amazon vendors). Amazon's own Vendor Retail Procurement FAQ says you have 24 hours to accept a purchase order, so design for the stricter figure and confirm the current requirement in your own Vendor Central documentation.

Step 6: Retry Safely

Now retries are cheap, because every step is protected. Use exponential backoff with random jitter so a hundred failed jobs don't all hit the API at once. Only retry transient failures such as timeouts and rate limits. Send hard failures like validation errors to a dead-letter queue with the raw payload attached.

A Worked Example (Illustrative)

Here's how it plays out with a made-up PO. The numbers are invented to show the sequence.

Result: one PO, one order, one acknowledgement, and no human involved.

Does This Apply to Direct Fulfillment?

The logic is the same, but the rules around the PO differ. Direct Fulfillment uses its own API. Amazon's guide for it says the acknowledgement is expected within 24 hours, that the order must be accepted or rejected in its entirety, and that a partial acknowledgement is not accepted (Direct Fulfillment Orders API use case guide). Build the same intake key, then check the acknowledgement rules for your program.

Common Mistakes in PO Intake Design

Deduplicating on PO Number Only

You'll swallow legitimate PO changes.

Checking for Duplicates in Application Code, Then Inserting

That "check then write" gap is exactly where race conditions live. Use the database constraint.

Hashing the Whole Payload and Using It as the Key

One reordered field or timestamp makes the same PO look new.

Retrying the Acknowledgement Without Checking Its Status

You can end up with conflicting acknowledgements.

Cleaning Up Old Keys Too Early

If you purge records after a day, a late retry looks brand new. Keep intake records for as long as a PO can plausibly be changed or re-sent. Your invoicing and dispute window is a good guide.

What to Monitor Once It's Live

You don't need a fancy dashboard. Four numbers tell you most of what you need.

1. Duplicates Suppressed per Day

A steady small number is healthy. A sudden spike means something upstream is misbehaving.

2. Same Key, Different Payload Count

This should be near zero. Investigate every one.

3. POs Stuck in RECEIVED or ORDER_CREATED

These are orders that started but never finished.

4. Time From PO Received to Acknowledged

It protects you from late-ack problems.

Pre-Launch Checklist

☐ Raw PO stored before any processing ☐ Unique constraint on vendor code + PO number + revision ☐ Payload hash stored and compared on conflict ☐ ERP enforces the same reference as unique, and you look up before you create ☐ Transport-level and PO-level acknowledgements tracked separately ☐ Ack transaction ID stored, status checked before resend ☐ Backoff with jitter, dead-letter queue for hard failures ☐ Intake records kept past the PO change and dispute window ☐ Alert on same-key, different-payload events

Wrapping Up

Duplicate purchase orders feel like an Amazon problem, but they're almost always an intake problem. Retries will keep happening, and that's fine. Your job is to make a retry boring.

Build the key carefully, let the database enforce it, and track every step that touches Amazon. Do that, and a retry stops being an incident and becomes a line in a log.