GitHub Auth + REST API: IBYOK Built for Builders

A secrets vault is only useful if your apps can actually fetch from it. A vault with a great UI but no programmatic interface is a password manager. A vault with no UI but a great API is a headache. The thing you want is both: humans manage keys through a clean dashboard, and your apps retrieve those keys via a clean, fast, authenticated API. IBYOK ships both.

This page is about the two pieces that make that work: GitHub authentication for humans, and a REST API for your apps. Neither is glamorous. Both are the reason IBYOK plugs into a builder's workflow without creating new friction.

GitHub auth: one less password

If you're an AI builder in 2026, you almost certainly have a GitHub account. It's where your code lives, where your open-source contributions live, probably where you've signed up for half a dozen developer tools via OAuth. Using GitHub as your identity provider for IBYOK means one less account to create, one less password to manage, and one less set of credentials that can leak.

The auth flow is what you'd expect: click "Sign in with GitHub," approve the scope, land back in IBYOK authenticated. Two-factor authentication on your GitHub account inherits to IBYOK automatically, because you never entered a separate password. The security properties of your GitHub account become the security properties of your IBYOK account, which for most builders is a net improvement.

There's a subtle benefit here too: GitHub auth means the identity is tied to a real developer account, not a disposable email. That reduces a whole class of abuse scenarios, and it means anyone accessing your IBYOK vault is traceable back to a GitHub identity — useful if you eventually onboard collaborators.

The REST API: keys on demand

The more interesting piece is the REST API. Your apps authenticate with an IBYOK token, hit a simple endpoint, and get back the actual API key they need to talk to OpenAI or Anthropic or whatever provider. It's a lookup — you ask for "my OpenAI key for staging" and IBYOK returns the current value.

This changes the shape of your application in a meaningful way. Instead of keys living in .env files that get deployed with your code, keys live in IBYOK and get fetched at runtime. You can rotate a key by updating the value in IBYOK, and every deployed instance of your app picks up the new key the next time it fetches. No redeploy. No environment variable dance. No "which server has the old key?"

It's the same pattern that enterprise secret managers like HashiCorp Vault or AWS Secrets Manager use, but the IBYOK version is scoped for individual builders — no cluster to run, no IAM policies to configure, no monthly minimum. You just call the endpoint.

Environment-specific controls

One of the real-world pains of secrets management is keeping staging and production keys separated. Your prod OpenAI key should never, ever accidentally get used by your staging environment — staging runs experimental code, staging has higher error rates, staging will absolutely blow through your production budget in a bad afternoon.

The old solution is discipline: don't mix up your .env files. The reality is that the discipline fails, because .env files get copy-pasted, backed up incorrectly, checked into repos accidentally, or left behind in Docker images. Someone on the team eventually mixes them up, and then you're hunting down "why did our staging server hit production's rate limit?" at 3 AM.

IBYOK handles this with environment-scoped keys. You create your OpenAI key twice — once as "openai-staging," once as "openai-prod." Each has different access controls, different budgets, different alert thresholds. Your staging app fetches "openai-staging" and literally cannot accidentally get the prod key, because it's not in that app's scope. The guardrails are structural, not procedural.

Rotation without redeploy

Here's the payoff that justifies the whole pattern. You realize you accidentally committed a key to a public repo. In the old world, you now have to rotate that key, find every place it's referenced, update each .env, redeploy every app, and pray you didn't miss one.

With IBYOK in the loop: you revoke the exposed key at the provider, create a new one, paste it into IBYOK. That's it. Every app that fetches from IBYOK picks up the new key on its next refresh. No redeploy. No searching through repos. No coordinating with teammates. The rotation is a three-minute task instead of a three-hour ordeal.

This isn't a theoretical benefit. Every builder does a key rotation eventually, and the difference between "painless" and "painful" is the difference between actually rotating keys when you should, versus letting compromised keys live in the wild because rotation is too expensive.

The onboarding story

Another scenario where the API shines: bringing on a collaborator or contractor. Pre-IBYOK, onboarding means either sharing .env files (bad), sharing individual keys via Signal or 1Password (annoying and not auditable), or provisioning new keys per person (tedious).

With IBYOK, you grant the collaborator access to specific keys — maybe just the dev keys, maybe with a lower budget. They sign in with their GitHub account. Their code fetches from IBYOK with their token. If they leave, you revoke their IBYOK access, and they lose access to everything at once — without you needing to rotate every shared key. Clean boundaries make collaboration safer.

The honest developer experience

Integration with your app is straightforward. Replace process.env.OPENAI_KEY with a call to the IBYOK API, cache the result for a reasonable window (to avoid hammering IBYOK on every API call), and you're done. Most integrations I've seen are ten to twenty lines of code.

For n8n users, there's an even cleaner path: IBYOK lookups as a credential type. You configure once, and every HTTP node in your flows can reference a key by name instead of hardcoding the value. Same pattern, same benefits, no code.

The API is REST, the docs are clear, the error messages are useful. It's a developer tool built by developers who knew what they wanted to exist. That usually translates into something you can ramp up on in an afternoon.

What to try first

Sign in with GitHub. Add one of your existing API keys to the vault. Pull that key into one of your apps via the REST API, instead of from your .env file. Run the app. Verify it still works.

Once that works, the mental shift is done. You've seen that keys can live outside your codebase without anything breaking. From there, migrating the rest of your keys is just repetition, and the benefits — rotation, environment separation, auditable access — start compounding with every key you move over.

— Jeff