Gumroad API Access Token: How to Create, Use, and Revoke It (2026)

Updated 2026-07-27 · GumKit guides

If you want to automate anything on your Gumroad account — pull your sales, bulk-edit prices, generate discount codes, or connect a tool like Zapier, n8n, or a Chrome extension — you'll hit the same first step: you need a Gumroad API access token.

The token is the key that lets software act on your account on your behalf, without you ever sharing your password. Generating one takes about two minutes and lives entirely inside your own Gumroad settings.

But three details trip almost everyone up, and most guides skip all three:

1. The Generate access token button is not on the form where you create the application. It's on the next screen.
2. A token you make this way is not a limited, read-only key. By default it carries every permission Gumroad exposes publicly.
3. Clicking Generate access token a second time does not rotate your token. It hands you the same one back — which means "just regenerate it" is not a way to revoke access.

This walkthrough covers the full flow as it works in 2026, what the token can actually do, how to fix the errors you'll hit, and how to genuinely shut it off.

What a Gumroad API access token actually is

Before clicking anything, it helps to know what you're creating.

Gumroad exposes a public REST API (version 2) at https://api.gumroad.com/v2. (The same API also answers at https://gumroad.com/api for backward compatibility.) Every request has to prove it's allowed, and that proof is the access token. Think of it as a long, random password that represents one specific permission grant rather than your whole login.

A few facts that shape everything below:

• The token is generated from an "application" you create inside your Gumroad settings. The application is just a container; the token is what you actually use.
• Gumroad's API is built on OAuth 2.0, and its configuration sets access tokens to never expire. Gumroad's own help documentation says the same thing in plain English: they do not expire the access token until it is revoked manually. Authorization codes, used only in the full OAuth flow, expire after 10 minutes.
• The token should be treated like a password. It goes in the header of every API request, and anyone who has it can act on your account within its permissions.
• There's a separate, heavier OAuth flow for apps that act on other people's Gumroad accounts. If you're wiring up your own account, you can skip that entirely.

That last point is the one that causes the most wasted afternoons. You do not need to implement OAuth, spin up a redirect server, or trade authorization codes to get a token for yourself. You create an app and click a button.

First: do you actually need a token?

Two common cases don't require one, and it's worth ruling them out before you go any further.

Verifying license keys. If all you want is to check whether a customer's license key is valid — the classic "does this person own my software?" check — Gumroad's license verification endpoint (POST /v2/licenses/verify) does not require authentication at all. It takes the license key plus a product identifier. Don't ship an all-powerful account token inside a desktop app just to do this.

Running commands yourself. Gumroad publishes an official command-line tool (gumroad-cli, installable via Homebrew or the install script linked from gumroad.com). Its gumroad auth login command runs a device-approval flow and stores a token for you, so you never hand-copy anything. It also reads a GUMROAD_ACCESS_TOKEN environment variable if you already have a token — the same one you're about to create.

If neither of those covers you, carry on.

Step 1: Open Settings → Advanced

Log in to Gumroad, then go to Settings → Advanced. The direct URL is:

https://gumroad.com/settings/advanced

An older bookmark at app.gumroad.com/settings/advanced serves the same page — both hosts work, and neither one bounces you to the other. (You may also see gumroad.com/settings/applications floating around in third-party guides. That URL returns a 404. Advanced is the right page.)

Scroll to the Applications section. This is Gumroad's developer area; nothing here is visible to your customers.

Step 2: Create an application

Under Create application, you'll find a short form. That's the whole thing — there is no plan to pick, no scope checklist, no approval queue:

Then click Create application.

Why the Redirect URI keeps failing

The rejections here come from a validation rule the form only whispers: hover the field and its tooltip reads "Redirect URI must have host and scheme and no fragment." In other words, the value must be a full URL with a scheme and a host, and no fragment.

In practice:

• http://127.0.0.1 — works.
• 127.0.0.1 — rejected. No scheme.
• localhost — rejected. No scheme.
• http://localhost — works.
• http://127.0.0.1/callback#done — rejected. Fragments aren't allowed.

The field is a required one, but for a personal token its value is meaningless. It only does real work in the full OAuth flow, where Gumroad sends an authorization code back to your app's address. Gumroad's own documentation tells personal users to enter localhost and move on. You can change it later at any time.

Step 3: Land on the Edit application page

Here's the step that derails people.

When you click Create application, Gumroad saves the app and sends you straight to its Edit application page. If you navigate away — or if you come back tomorrow — you won't find your token on the Advanced settings page. All you'll see is your app listed under Your applications with Edit and Delete buttons.

Click Edit. The token controls only exist on that page. If you're staring at the create form wondering where the token button went, this is why.

On the Edit application page you'll now see two read-only values:

• Application ID (this is your client_id)
• Application Secret (this is your client_secret)

These two matter only if you later build the full OAuth flow so other people can connect their accounts. For a personal token you can ignore them — but still keep the secret private, since it's part of your app's identity.

Step 4: Generate your access token

On the Edit application page, click Generate access token.

The button label flips to "Generating…", and a new read-only Access Token field appears with your token in it. Copy it somewhere safe. This single string is what you'll paste into whatever tool or script needs API access.

Two behaviours worth knowing, because they're the opposite of what most APIs do:

You can retrieve the same token later. Lost the string? Go back to Settings → Advanced, click Edit on your app, and click Generate access token again. There's no "you'll only see this once" one-shot reveal here.

Clicking the button again does not rotate anything. Under the hood this is a get-or-create operation: Gumroad looks for an existing, unrevoked token on that application and returns it if it finds one. You only get a brand-new string when no active token exists. So if you were planning to "just regenerate it" to cut off a tool that has your token — that won't work. See the revocation section below for what actually does.

Step 5: Test that it works

Confirm the token with a single read-only request. The recommended form uses the Authorization header:

curl https://api.gumroad.com/v2/user \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

A valid token returns your account details as JSON with "success": true. Then try your products:

curl https://api.gumroad.com/v2/products \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

Gumroad also still accepts the token as a query parameter, and you'll see that style in some of its own older examples:

curl "https://api.gumroad.com/v2/products?access_token=YOUR_ACCESS_TOKEN"

Both work. Prefer the header. Gumroad's documentation calls it the preferred method because it "keeps tokens out of URLs and server logs" — and a query string full of credentials has a habit of ending up somewhere you didn't intend, from browser history to a proxy log.

What your token can actually do

Scopes define what a token is allowed to do. Here's the part almost nobody mentions: when you create an application in the dashboard, Gumroad assigns it the full set of public scopes automatically. There is no scope picker on that form. Your "personal token" is an everything token.

The scopes a dashboard-created application receives, and roughly what they govern:

Other scopes exist in the OAuth layer but are not handed to an application you create for yourself. refund_sales is one of them. mobile_api, creator_api, helper_api and unfurl are reserved for Gumroad's own internal apps. And view_public — the OAuth default scope you'll see cited elsewhere — isn't in the set either, because a dashboard application is created with the public list above instead.

Missing refund_sales is less reassuring than it sounds. The refund endpoint accepts either refund_sales or edit_sales, and edit_sales is on the list — so your personal token can still issue refunds.

Scope selection matters most in the OAuth consent dialog, where a third-party app asks for only the permissions it needs and you approve them. That's a real, meaningful limit. A dashboard-generated personal token doesn't go through that dialog, so treat it as full account access: it can read every customer email you've ever collected, change your prices, and issue refunds.

That's not a reason to avoid it. It is the reason to keep it out of client-side code, public repos, and screenshots.

Personal token vs. full OAuth

If you're a seller wiring up your own catalog, the left column is all you need.

Troubleshooting: the errors you'll actually hit

The API uses standard HTTP status codes, but it has one habit that catches people out: some failures come back with HTTP 200 and "success": false in the body. Always check the success field, not just the status code.

Two more practical notes:

Pagination. List endpoints return a next_page_key. Pass it back as page_key to walk through results. The older page parameter is deprecated — if you're following a tutorial that uses it, you're following an old tutorial.

Rate limits. Gumroad enforces rate limiting and will return 429, but it does not publish specific numbers — so any exact requests-per-minute figure you see quoted is somebody's observation, not a documented limit. Build for it anyway: use exponential backoff on 429, cache what you can, and prefer webhooks (/v2/resource_subscriptions) over polling for anything real-time. If you're pushing writes across a large catalog, pace them deliberately rather than firing everything at once.

How to actually revoke a token

Because the token never expires on its own, you are responsible for turning it off. And since regenerating doesn't rotate it, there's really one reliable answer:

Delete the application. From Settings → Advanced → Applications, click Delete on the app and confirm. This revokes every access token and authorization grant tied to that application at once, and access stops immediately for anything still holding the old string.

Know what else goes with it: deleting an application also removes any webhook subscriptions (resource subscriptions) registered under it and denies pending device authorizations. If you have live webhooks pointed at that app, they die with it — so re-register them under whatever app replaces it.

A separate page, Settings → Authorized applications, lists third-party apps you have granted access to via OAuth. That's where you revoke someone else's app. It's not where your own tokens live — those are under Advanced.

A few habits that keep you safe:

• Never paste your token into a public repo, a screenshot, or a support chat. It's a password with refund powers.
• Use one application per tool. Since deletion is the revocation mechanism, one app per integration means you can cut off a single tool without breaking the others. If everything shares one app, revoking one thing revokes everything.
• If a tool stores your token on its own servers, understand that you're trusting that server. Tools that keep the token in your browser only never see it on their backend — a meaningfully smaller attack surface.

That last distinction matters more than people realize, especially if the "tool" is a browser extension.

When not to use a personal token

• Don't embed it in anything you distribute. Desktop apps, mobile apps, client-side JavaScript — all of it can be decompiled or read. For license checks in shipped software, use the unauthenticated license verification endpoint instead.
• Don't use it to access someone else's account. That's what the OAuth flow exists for. There is no legitimate way to use your personal token against another seller's data.
• Don't share one token across a team. You can't tell who did what, and revoking it locks everyone out simultaneously.
• Don't commit it. Use environment variables. The official CLI reads GUMROAD_ACCESS_TOKEN for exactly this reason.

Where this token gets used: tools built on your own API access

The whole reason to generate a Gumroad API access token is to let a tool act on your account safely. GumKit is one example of how that's supposed to work — and a useful checklist for evaluating any tool you hand a token to.

GumKit is an independent Chrome extension for Gumroad sellers. It is not affiliated with, endorsed by, or sponsored by Gumroad — it's a third-party tool that talks to Gumroad's own official API on your behalf. Here's how it uses the token you just created:

• You bring your own token. You generate it yourself with the exact steps above, then paste it in. GumKit never asks for your Gumroad password and doesn't log in for you.
• The token stays in your browser. It's stored in chrome.storage.local on your machine. There is no GumKit server holding your credentials, so there's no backend that could leak them.
• It only calls the official API v2 (api.gumroad.com/v2). No scraping, no automating clicks in the dashboard, no rate-limit tricks.
• Bulk jobs are paced and resumable. Writes run through a throttled queue with a progress bar. Closing the popup doesn't kill the run — it picks up where it left off — and you can cancel it mid-run. It paces writes instead of hammering the API and collecting 429s.
• You stay in control. Because it's your token hitting your account, deleting the application in Gumroad's settings cuts off access immediately.

With that access in place, the one-at-a-time chores the dashboard makes tedious become single passes:

• Bulk discount codes — define one offer code and apply it across every selected product instead of retyping it product by product (see the bulk discount codes guide).
• Per-region parity pricing — generate explicit, controllable region codes from an editable table (more in PPP pricing on Gumroad).
• Bulk price changes — set a fixed price or apply a ± percentage across many products at once (how to change prices on every product).
• Customer CSV export — pull your full sales history into a spreadsheet (walkthrough: export Gumroad customers to CSV).
• AI listing SEO — improve product titles and descriptions using your own OpenAI key.

GumKit is free to use. The point isn't the tool — it's that a well-built integration uses exactly the token you generated, keeps it on your side, and rides on Gumroad's official API rather than working around it. That's the bar to hold any tool to.

FAQ

Where do I find my Gumroad API key?

Gumroad doesn't use the term "API key" — the equivalent is an access token. Go to Settings → Advanced, create an application, then click Edit on it and press Generate access token. The token controls are on the application's edit page, not the create form.

Do I need to know how to code to get a Gumroad API access token?

No. Generating a token for your own account is entirely point-and-click. You only need code if you're calling the API yourself; a finished tool or the official CLI handles the requests for you.

Does the Gumroad access token expire?

No. Gumroad's OAuth configuration sets access tokens to never expire, and its documentation confirms the token stays valid until it's revoked manually. That convenience is exactly why you should treat it like a password.

I clicked "Generate access token" twice. Do I have two tokens?

No. The button returns your existing active token if one exists, and only creates a new one when there isn't one. It's a retrieval button as much as a generation button — which also means it can't be used to rotate a compromised token.

What should I put in the Redirect URI field?

For a token tied to your own account, enter http://127.0.0.1. It must include the scheme (http://) and have no #fragment, or the form will reject it. The value itself is meaningless for personal use, and you can change it later.

How do I revoke my Gumroad API token?

Delete the application from Settings → Advanced → Applications. That revokes every token and grant tied to it immediately. Regenerating the token does not revoke the old one. Note that deleting the app also removes any webhook subscriptions registered under it.

Why am I getting a 401 Unauthorized error?

Start with the header. It must read Authorization: Bearer YOUR_TOKEN — the literal word Bearer, one space, then the token with no quotes or trailing whitespace. If the header is right, confirm the token still exists by checking whether its application is still listed under Advanced. A 403 or a "success": false message about authorization means the opposite problem: the token is fine, but it lacks the scope.

What's Gumroad's API rate limit?

Gumroad rate-limits the API and returns 429 Too Many Requests when you exceed it, but the specific thresholds aren't publicly documented. Handle 429s with exponential backoff, and use webhooks instead of polling where you can.

Is it safe to give my token to a third-party app?

It depends on the app, and the stakes are higher than people assume — a dashboard-generated token carries all public scopes, including reading customer data and issuing refunds. Safer designs use a token you generate, store it on your own device rather than their server, and call the official API instead of scraping. Give each tool its own application so you can revoke one without breaking the rest.

The takeaway

Getting a Gumroad API access token is a five-minute job once you know where the button hides:

1. Settings → Advanced → Applications
2. Create application — name it, and put http://127.0.0.1 in Redirect URI
3. Click Edit on the app you just made
4. Click Generate access token and copy the string
5. Test it with curl https://api.gumroad.com/v2/user -H "Authorization: Bearer YOUR_TOKEN"

The token doesn't expire, it arrives with full public-scope access, and regenerating it won't take it back. So the real discipline is on the security side: one application per tool, never in a repo or a screenshot, and delete the application when you're done with an integration.

Once you have it, that token is the single key behind every Gumroad automation, from a one-line curl to a full extension. If your reason for generating it is to stop doing repetitive catalog work by hand, GumKit uses exactly this token — your own, stored in your browser, on Gumroad's official API — to turn those one-at-a-time chores into single passes. Free to use, with no middleman between you and your own account.