Gumroad

REST API at api.gumroad.com/v2/. Products: GET/POST/PUT/DELETE for product CRUD with name, price, description, and configuration. Sales: GET /v2/sales returns purchase records with buyer email, product, price, and custom fields. License verification: POST /v2/licenses/verify checks a license key's validity and increments use count. Subscribers: GET /v2/products/{id}/subscribers lists active subscribers for membership products. Pings (webhooks): POST to configured URL on each purchase with sale details including product, price, email, and custom fields. The API is simple — few endpoints, straightforward payloads. No batch operations. No complex query filtering on sales beyond date range. The data model is flat: products → sales and products → subscribers. Pagination uses basic page/per_page.

API errors return JSON with success (boolean) and message fields. Standard HTTP status codes. Rate limits are not publicly documented — agents should implement reasonable backoff. The ping webhook system is fire-and-forget with retries — agents should acknowledge pings quickly and process asynchronously. License verification is stateful: each verification call can increment the use count, so agents must be careful not to consume uses unintentionally. Sale records are eventually consistent — recently completed purchases may not appear immediately in the sales API. The main reliability consideration: Gumroad is a smaller platform — API stability and feature velocity are lower than enterprise payment platforms. For agents with simple digital commerce needs, the API is adequate.

Gumroad is designed for individual creators selling digital products — ebooks, courses, software, memberships. For agents, the API is intentionally simple: manage products, check sales, verify licenses, and manage subscribers. The 'ping' webhook system notifies on purchases. License key verification enables software licensing workflows. The API doesn't cover payment processing details (Gumroad handles all payment collection). For agents building creator commerce integrations — linking sales to fulfillment, verifying licenses, managing subscriber access — Gumroad's API covers the basics. The limitation: the API is read-heavy and management-light. Agents can't create complex product configurations, manage pricing dynamically, or handle custom checkout flows. It's a platform for selling simple digital goods, and the API reflects that scope.

OAuth 2.0 authorization code flow for third-party applications. Personal access tokens for direct account access (no user consent needed for own account). Access tokens are passed via access_token query parameter or Authorization header. Token scope is all-or-nothing — no granular permissions. OAuth tokens don't expire by default. For agents integrating with their own Gumroad account, the personal access token approach is simplest. For agents building integrations for other Gumroad users, OAuth is required. No API key approach — only OAuth tokens. The auth model is simple but lacks modern features (token expiry, scoping, rotation). For agents, the main security consideration is that tokens grant full account access.

API documentation at app.gumroad.com/api is a single page covering all endpoints. The documentation is minimal but complete for the API's scope — each endpoint has parameters and a response example. OAuth flow documentation covers the authorization URL, token exchange, and refresh. No official SDKs. Community wrapper libraries exist for various languages with varying maintenance quality. The single-page API reference format means the entire API can be understood in 15 minutes. No interactive API explorer or playground. No developer community forums. For agents, the simplicity is the documentation's strength — there's nothing to navigate, no conceptual hierarchy, just endpoints and parameters. The main gap: error handling and edge cases aren't well-documented.