Create many (many) Discount Redemption codes quickly

We are using the discountRedeemCodeBulkAdd mutation to generate many unique codes that we can then send to customers in response to some event (eg: Abandoned Cart). Our approach has been to keep a cache of generated codes ready to handle bursty traffic. When the cache gets low, we call discountRedeemCodeBulkAdd to generate more. This has been working ok so far. However, we are looking to extend it to a campaigns use case. We need to be able to send out 10s of thousands of codes at once. Since each discountRedeemCodeBulkAdd mutation is limited to generating 250 codes per request, we’d need to start 40-200 bulk jobs. And we’ve noticed that beyond just 3-5 concurrent jobs starts to result in slower job completion times. We benchmarked 40min to generate 250k codes.

Are there any other options for facilitating this use case? Thinking outside of the box, is there another way we can integrate with the checkout page to capture codes entered into the coupon field and only generate the redemption codes at that point in time?

Hi @Devon_Dickson, thanks for the question! I had a look internally and can confirm your cache ahead approach is the standard way to absorb bursty demand, and the 250 cap on discountRedeemCodeBulkAdd is a hard limit, so there’s no single call that creates more than that and no faster bulk endpoint to reach for. Each call kicks off an async bulk creation job, and the drop off you saw past 3-5 concurrent jobs lines up with what others hit. More parallelism doesn’t really buy you more throughput, it mostly just queues the work.

For the campaign use case, the realistic play is to decouple generation from send time. Generate the pool ahead of the campaign (overnight, or whenever your load is low), keep concurrency in that 3-5 band, poll each job’s done and failedCount fields, and retry any failed batches with backoff. If you front load a 250k pool before the send rather than at send time, the 40 minutes stops mattering because nobody is waiting on it.

On the checkout idea, there’s a version of it that works, but only if you’re on Shopify for enterprise. Functions are sandboxed and can’t make network calls by default, and the exception is network access for Discount Functions, which is limited to Shopify for enterprise plans using custom apps and has to be enabled by Shopify (no dev stores). If you clear that bar, you declare a fetch target, Shopify makes an HTTP request to your service on the function’s behalf and passes the code the shopper entered, and there’s a tutorial for this exact pattern of validating codes against an external system and applying the discount at checkout. That would let you validate or mint codes on demand in your own system instead of pre creating them all in Shopify. It approves the discount based on your service’s response rather than writing a persistent redeem code back into Shopify, so per code reporting would live on your side. If the merchant isn’t on enterprise, this route isn’t available and generating ahead stays the play.

That would let you validate or mint codes on demand in your own system instead of pre creating them all in Shopify. It approves the discount based on your service’s response rather than writing a persistent redeem code back into Shopify, so per code reporting would live on your side. If the merchant isn’t on enterprise, this route isn’t available and generating ahead stays the play.

It’s also worth confirming whether these actually need to be unique per recipient. If the uniqueness is really about one time use or attribution rather than a genuinely distinct code per person, you can often skip mass generation entirely. A single code with a usage cap, an automatic discount, or a shareable discount link that applies the offer via URL all give you campaign behavior without pre generating tens of thousands of codes. If you do need a distinct code per recipient (printed cards, per user tracking), then the bulk pipeline above is the way to go.

Thanks Donal, this is exactly the reply I was looking for!