Gumroad and CodeWords: automating what happens after the sale

Gumroad is deliberately simple. Somebody pays, they get the file, you get the money. That simplicity is the product, and it is also why creators end up doing a surprising amount by hand around it: tagging the buyer in their email tool, adding them to a community, issuing a licence, checking whether the person asking for support actually bought anything.

None of that is Gumroad's job. All of it happens every time somebody buys, which makes it the clearest possible case for automation.

What we'll cover

• What happens after the sale, manually
• What the Gumroad API reaches
• Connecting it to CodeWords
• Eight automations worth building
• Refunds, chargebacks and access
• Building it so it survives
• Limits worth knowing about
• What to build first
• Frequently asked questions

What happens after the sale, manually

Tagging the buyer. Your email list needs to know they bought, so they stop getting the sales sequence and start getting the customer one. Nothing does this on its own.

Granting access. A community, a private channel, a course platform, a shared folder. Each one is a separate manual step that happens at whatever hour the sale did.

Issuing something. A licence key, a personalised file, a certificate. Anything that is not the same file for everybody.

Verifying purchases. Somebody emails asking for help, and answering means checking whether they bought, which product, and when.

Reporting. Revenue by product, refund rate, which launch worked. Available in the interface and not in the form you want it, and never where your other numbers live.

Reconciling. Gumroad's figures against your accounts, your email list, and whatever else you count.

Every one of these is triggered by the same event and none of them is hard. They are simply relentless.

What the Gumroad API reaches

Sales can be listed and read, with the product, the buyer's email, the amount, variants chosen, and any custom fields you collected at checkout.

Products can be listed and read, including variants and prices, and some properties updated.

Subscribers cover recurring memberships, with their status, which matters if you sell anything ongoing.

Licence keys can be verified, enabled, and disabled, which is the mechanism behind software licensing on the platform.

Offer codes can be listed and created, which supports personalised discounting.

Ping and webhooks notify your endpoint on sale, refund, dispute, cancellation, and subscription events. This is the important one: almost every useful automation here starts with a ping.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which event, and what should happen in which systems.
3. Authorize the connection with your Gumroad access token, and point the ping or webhook at the automation.
4. Describe the exceptions: a buyer whose email is already on your list, a refund for a purchase that granted access, a duplicate ping.
5. Test with a real purchase of a free or heavily discounted product, which is the only test that exercises the whole path.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Eight automations worth building

Tag the buyer in your email platform. Apply the product tag, remove the prospect tag, and add them to the post-purchase sequence. The most valuable automation here, because segments that lag behind sales send the wrong email to actual customers.

Grant access. Invite to the community, add to the course platform, share the folder. Whatever "they bought, now they need in" means for your product.

Issue licences or personalised assets. Generate the key or the personalised file and deliver it, recording what was issued against the purchase.

Purchase verification for support. A lookup you or your support tool can use to confirm what somebody bought before answering, without opening the Gumroad dashboard.

Revenue reporting where your other numbers are. Daily or weekly figures by product into a sheet or a channel, with comparison against the previous period.

Launch tracking. During a launch, sales by hour with the running total and the referrer breakdown, so you can see what is working while it is still happening rather than afterwards.

Subscription lifecycle handling. Membership cancellations and failed payments triggering the right access changes and the right message, rather than being noticed weeks later.

Reconciliation. Gumroad's sales against your accounts and your email list, with differences reported. The differences are usually informative.

Refunds, chargebacks and access

The part most creators build last and should build second.

Refunds should revoke what was granted. If a purchase added someone to a community and issued a licence, a refund should reverse both. Building the grant without the revoke means your paid community slowly fills with people who did not pay.

Chargebacks are different from refunds. They arrive later, they carry a fee, and they sometimes indicate fraud rather than dissatisfaction. Treat them as a separate signal rather than folding them into the refund path.

Be careful about automatic revocation. A refund on one product should not remove access to a different one somebody still owns. This requires the automation to know what each purchase granted, which is why recording that at grant time matters.

Keep the record after the revoke. Somebody who bought, refunded, and later buys again is a normal pattern, and the history is useful context.

Do not send an automated message that sounds accusatory. A refund is usually somebody deciding the product was not for them, which is fine and does not warrant an email implying otherwise.

Building it so it survives

Make it safe to run twice. Pings retry. Granting access twice is usually harmless; sending a licence key twice can mean two keys issued for one purchase, which is a support conversation later.

Use the sale identifier, not the email, as the key. Emails repeat across purchases. The sale ID is what makes an automation safely repeatable.

Verify the ping. Confirm a notification genuinely came from Gumroad before acting on it, since an endpoint that grants access on any request that reaches it is an endpoint somebody will eventually find.

Record what was granted. Which community, which licence, which folder. Revocation is impossible to do correctly without it.

Report the outcome. A daily line with sales processed and anything that failed. A grant automation that silently stops is discovered by a customer asking why they have no access.

Limits worth knowing about

Rate limits apply, so bulk historical operations need pacing rather than a tight loop.

Ping delivery is not guaranteed to be exactly once, which is why idempotency matters, and it is occasionally delayed.

Historical sales access is paginated and an automation reading only the first page will silently under-report, which is invisible until somebody checks a total.

Custom checkout fields are defined per product, so an automation expecting a field will not find it on products where it was never configured.

Payout timing differs from sale timing. An automation reporting revenue is reporting sales, which is not the same as money in your account, and conflating them produces a reconciliation that never balances.

What to build first

Tagging the buyer in your email platform. It runs on every sale, the failure is visible and embarrassing if you skip it, and it is easy to verify by buying your own product and checking the tag appeared.

Two habits make the difference. Run it alongside whatever you do manually for a few sales and compare, since the exceptions are where you learn what your rules are missing. And have it report what it processed, because a grant automation that quietly fails is found by a customer rather than by you.

Frequently asked questions

How do I know a ping is really from Gumroad?

Verify it before acting. An endpoint that grants community access or issues licences on any request that reaches it is an endpoint worth finding, and someone eventually will. This is the one security step in the whole setup that genuinely matters.

What happens if a ping is delivered twice?

Your automation runs twice. Use the sale identifier as an idempotency key so the second run recognises it has already handled that sale. Granting access twice is usually harmless; issuing two licence keys for one purchase is a support conversation.

Can I sync buyers to my email list automatically?

Yes, and this is the most common reason to connect anything to Gumroad. Sync the purchase as a tag and the buyer as a subscriber, respecting whatever consent they gave at checkout rather than assuming a purchase implies marketing permission.

How do I handle refunds?

Reverse what the purchase granted, and record the refund rather than deleting the buyer. The important detail is that revocation should be specific to what that purchase gave them, not a blanket removal, since somebody may still own other products.

Can I verify a customer's purchase from a support tool?

Yes, and it removes a genuinely annoying step. A lookup by email returning what they bought and when means whoever is answering does not open the Gumroad dashboard, and it works equally well as an automation enriching a support ticket.

Does this work for memberships as well as one-off sales?

Yes, and memberships need more care, because cancellations and failed payments need to change access. Handling the cancellation path is the half people skip, and it is the half that determines whether your paid community stays paid.

Why do my revenue numbers not match my bank?

Because sales and payouts happen on different timelines, with fees and refunds in between. Report them as separate figures rather than trying to reconcile sales directly against deposits, which is a reconciliation that will never balance and will consume an evening finding that out.

Can I personalise what each buyer receives?

Yes, and it is one of the better reasons to automate here. A licence key, a personalised PDF, or a file named for the buyer can be generated on purchase and delivered, which Gumroad's own delivery does not do. Record what was issued against the sale so you can reissue it when somebody loses it.

How do I handle a buyer who purchases twice?

Decide whether that is an error to flag or a legitimate second purchase, because both happen. Using the sale identifier as the key means your automation will treat them as separate events correctly, and a quick check for a recent identical purchase catches the accidental double-click.

What is the most common thing people forget?

Revoking access on refund. Granting is satisfying to build and revoking is not, so the grant ships and the revoke does not, and the paid community slowly fills with people who were refunded months ago.

How do I handle a buyer who wants support before I have processed their sale?

Look up the sale directly rather than relying on your own records having caught up. A verification lookup by email against Gumroad answers the question immediately and works even when a ping was delayed or your automation was briefly down.

Should the automation email buyers directly?

Only for things Gumroad does not already send, such as a licence key or access details, and only where the buyer expects it. Duplicating the purchase confirmation is a common early mistake that makes a smooth purchase feel spammy.

How do I reconcile Gumroad against my accounts?

Compare sales against sales and payouts against deposits, as two separate reconciliations. Fees, refunds, and payout timing sit between them, and attempting to match sales directly to bank deposits is a reconciliation that cannot balance.

Related reading

• ConvertKit and CodeWords
• CodeWords integrations and templates