Developer portal

Your developer portal is where your customers sign in, create and rotate their API keys, and check their usage. It shows your app's name, logo and color, so it looks like part of your product rather than ours.

Address

Each app's portal has its own address, https://{your-app}.usagerail.app, shown on the app's Portal page in the console. You can also give it a domain of your own.

The portal runs on its own domain, so its cookies never reach usagerail.com. Its pages also refuse to be framed by other sites, except the usage widget, which is made to go in your dashboard.

Custom domain

You can serve the portal from your own address, such as developers.example.com. Each app can have one, and your UsageRail plan sets how many you can have across all your apps: 1 on Free and Starter, 3 on Growth, 10 on Scale.

1. On the app's Portal page, under Custom domain, enter the hostname. Use a subdomain: a bare domain such as example.com can't point at the portal.
2. Where you manage DNS for that domain, add the two records the console shows: a CNAME from the hostname to cname.vercel-dns.com, and a TXT record at _usagerail. followed by the hostname. On Cloudflare, set the CNAME to DNS only, not proxied.
3. Click Check now once the records are in. We also check on our own, but those checks can be up to an hour apart. Once both records are found, we set up HTTPS for the hostname, which usually takes a few minutes, and the portal goes live there. The default address keeps working. If the records disappear before that, setup starts over with a new TXT value.

The portal is hosted on Vercel. If your domain is already used in another Vercel account, for example by your own website, Vercel asks for one more TXT record, and the console shows it. If the hostname itself is still added to one of your Vercel projects, remove it there first.

While the domain is live, sign-in links and alert emails send customers to it. Keep both records in place: we check them every hour. If either is missing two checks in a row, the portal stops answering at that address, everyone signed in there is signed out, and we email you. To bring it back, add the records the console shows then. The TXT value changes at that point, so whoever controls the domain later can't revive it with the old one. If the domain stays paused for 30 days, we remove it, and while it's paused, another app can take the hostname by adding its own records.

Removing the domain stops the portal there at once and signs out everyone who was signed in on it. If you add the same hostname to the same app again within 30 days, it uses the same TXT record.

Who can sign up

Under Portal > Who can sign up:

Signing in

Customers sign in with Google, GitHub or their email address. Google sign-in works for Gmail and Google Workspace addresses; anyone else is asked to use the emailed code instead. GitHub sign-in uses the account's verified primary email. Both consent screens name UsageRail. With email, the portal sends a 6-digit code and a link, each good once and for 15 minutes: they type the code on the sign-in page, or open the link and confirm with a Sign in button. Whichever way they sign in, your Who can sign up setting applies to that email. A session lasts 30 days.

Suspending a customer in the console signs them out at once, and their next request to the portal is refused. You can also sign a customer out without suspending them, from their page in the console.

Your backend can sign a customer in directly, with a link from POST /v1/consumers/{id}/portal-link in the server API. Signing in that way doesn't confirm their email, so the portal doesn't send them alerts until they confirm it: by signing in once with a code or link the portal emailed them, or from Settings.

What your customers can do

• Overview: their plan, this period's usage against the quota, their rate limits and how many keys they have.
• API keys: create a key with a name, rename it, rotate it, or revoke it. A new key is shown once. When they rotate a key, they pick how long the old one keeps working, from 1 hour to 30 days, 24 hours by default. A revoked key starts failing within about 20 seconds. See API keys.
• Usage: requests and units by day and by endpoint, for the last 7 or 30 days.
• Plan: their current plan and the plans you've marked as public. Changing plans needs billing through Stripe, which isn't live yet, so for now the plan page points customers to your support email.
• Settings, under the account menu: change the email they sign in with, and turn quota alerts and new-key emails on or off. A new email takes effect only after they enter the code sent to it, or open the link in that email in a browser where they're signed in. A customer whose email isn't confirmed yet can confirm it here the same way. The old address, if it was confirmed, gets a note that it changed. What they turn off here doesn't change the quota alerts you get about them.

Each customer can have 10 active keys at once by default. Change it under Settings > Keys per customer, to anything from 1 to 50. An old key that's still within its rotation window counts toward the limit until it expires.

Branding

Footer

The footer links to your docs, terms, privacy policy and support email, if you fill them in. The support email is also where the plan page sends customers who want to switch plans.

The footer also shows a small "Powered by UsageRail" link. On UsageRail's Free plan it always shows; on paid plans you can hide it. Either way, you can add nofollow to it.

Search engines

Every portal page is marked noindex, so your customers' dashboards don't show up in search results.