Platform teams can take key requests on the docs site. The form captures the company and the use case so you are not issuing production credentials from a Twitter DM.
Notify the partner or platform engineer who issues keys.
Sandbox vs production in the copied select.
Edit the message placeholder.
Reply with docs and a sandbox first by default.
An API access form is a human review gate before credentials. Self-serve keys are better when you have abuse controls; many B2B APIs in the US and UK still want a conversation about rate limits, data processing, and whether the caller is a competitor. The inquiry pack is the right shape: company, type, message.
This is not OAuth. You will still provision keys in your admin tool. The form stops ‘please send API key’ emails with no callback URL or intended QPS.
You need a use case and a responsible email, not a credit card on a public HTML form.
Never ask them to paste existing secrets into this form. Rotate anything that arrives anyway.
Stripe-style self-serve is the product ideal. A form is how you start without a full developer portal.
Docusaurus and ReadMe both allow HTML embeds or a linked page.
Build when abuse, billing, and keys-at-scale demand it.
Use if every API user is a signed partner. Heavy for indie hackers.
Unstructured. You will lose the thread when the intern leaves.
Put the form on /docs/api/access next to rate-limit copy and the DPA link.
UK/EU customers may need a DPA before production. Collect the ask here; send the DPA from legal, not as an unauthenticated upload.
No. It is an inquiry. Provision in your own system.
Keep docs public. Gate credentials, not the spec, unless you have a reason.
Use inquiry type Other and a generous sandbox policy in your reply.
Send those after this form, via a proper file path, not this textarea.
Capture repro steps, severity, and environment from users on your site.
Let customers pitch product ideas with context, not a one-line tweet.
A lighter intake than a feature request for culture, process, or UX niggles.