API developer portal with self-serve keys and billing

An API developer portal for a paid API is where your customers sign up, create and rotate API keys, pick a plan, pay and check their usage, without emailing you. UsageRail hosts one for you, with your branding, payments through your own Stripe account and no gateway in front of your API. The portal is live; paying through Stripe isn't yet, so for now customers start on your default free plan and you change plans for them in the console.

What a portal for a paid API needs

A lot of developer portal software comes out of API management, where the portal's job is to publish a catalog of APIs and their reference docs. When you sell one API to outside developers, the portal is mostly about accounts and money:

It also has to look like your product: your name, logo, colors and domain.

How this differs from API-management portals

Kong and Azure API Management both ship portals built around the catalog. Kong says its Konnect Dev Portal lets developers "browse and search API documentation, try API operations, and manage their own credentials". Azure's developer portal is generated from the APIs you publish in API Management, with a console for trying calls and subscriptions that issue keys.

With Azure, taking payment is left to you: its monetization guide tells you to choose a payment platform such as Stripe and points to a sample project for wiring it up. And in platform engineering, "developer portal" means something else again: internal tools such as Backstage, "an open source framework for building developer portals", which catalog a company's own services.

What UsageRail's hosted portal includes

Each app gets a portal at your-slug.usagerail.app. You can also move it to your own domain on any plan (1 custom domain on Free and Starter, 3 on Growth, 10 on Scale): add the TXT and CNAME records we give you, and we issue the certificate once both check out.

Customers sign in with Google, GitHub or their email address, where we send a 6-digit code and a link. There are no passwords for you to store or reset. Inside, they get seven pages:

You decide who gets in. Sign-up can be open (anyone can join and starts on your default plan), invite-only (only emails you invite can sign in) or approval-based (people apply, and can't pay or get keys until you approve them).

Keys use a fixed format, your prefix plus live or test plus a checksum, so the SDK rejects mistyped keys without a network call. You can try the format in our API key generator. We store only a SHA-256 hash, and the full key is shown once, when it's created. Rotating creates a new key and gives the old one an expiry, 24 hours by default and up to 30 days, so customers can switch over without downtime. Each customer can hold 10 active keys by default, and you can set the cap anywhere from 1 to 50. Keys and limits are checked inside your own server, as covered in API rate limiting.

Payments go straight into your Stripe account through Stripe Checkout. UsageRail never holds the money and takes no percentage of it. The usage the portal shows comes from the SDK's per-customer counts; API analytics explains what's recorded and what's billed.

The portal carries your name, logo, primary color, support email, docs link, and your own terms and privacy policy. On the Free plan its footer shows a "Powered by UsageRail" badge; from Starter up you can remove it. Plan limits are on the pricing page.

Embeds for your own site and dashboard

If you'd rather keep customers on your own site, two embeds cover the parts they look at most. The pricing table is one script tag and a <usagerail-pricing> element; its buttons go to checkout and follow your sign-up mode, so on an invite-only app they ask people to sign in before buying. The usage widget goes into your own dashboard, so customers can see this period's usage without leaving your app.

Build it yourself or use a hosted portal

If you already have a dashboard with login and only need a keys page, building it yourself is often the right call. The work grows once plans and money are involved:

• Email sign-in needs hashed, single-use codes and links with a short expiry, a cap on wrong guesses, and a confirm step so email scanners that open links don't use them up.
• Keys need enough randomness, hash-only storage, one-time display, rotation with overlap, and revocations that reach every server quickly.
• Billing needs plans kept in sync with Stripe through webhooks, rules for plan changes in the middle of a period, and a path for failed payments. Stripe's customer portal handles cards and invoices, but its docs say customers can cancel a subscription with usage-based billing there and can't update it, so plan changes need your own page.
• Usage needs counting per customer and endpoint, visible during the period, matching the invoice to the unit.
• Custom domains need DNS checks, certificates, and sessions that stay on their own hostname.

None of it is exotic, but all of it needs maintaining after launch, and that's time not spent on your API.

Hosted alternatives exist, with different trade-offs. Zuplo's developer portal covers pricing, plan selection, checkout, subscription management, usage dashboards and key management, but Zuplo is a gateway that "sits between your clients and your backend APIs". Kinde has a self-serve portal, a pricing table and metered features, but it creates a new Stripe account for you rather than connecting the one you have.

Limits

• The portal doesn't host API reference docs. Keep them where they are and set your docs link; the portal points to it.
• Each customer account has a single sign-in email for now. Letting customers invite teammates to share keys, usage and billing is planned for after launch.
• Plan changes that involve a usage-based price take effect at the end of the billing period. Upgrades between flat-fee plans can take effect right away.
• UsageRail isn't a merchant of record and doesn't collect or remit sales tax. You can turn on Stripe Tax in your own Stripe account.
• There are no gateway features: no caching, request rewriting or firewall.