Integrations · Sign in with Pikeway
When to use Sign in with Pikeway
Your users connect their own Pikeway account to your app with OAuth 2.1. Your app calls APIs on their behalf, and every call is paid from their balance, within a spending limit they choose.
How it works
- Your app sends the user to the Pikeway consent page. They sign in (or sign up) and see your app's name, what it can do, and where they'll be sent back to.
- They pick a spending limit for your app: $1, $5, $20, $100 or no limit, and click Allow.
- Your app exchanges the authorization code for an access token. The token is a Pikeway key (
pk-…) that belongs to the user, carries that limit, and works on every gateway endpoint. - In the user's Console → Keys, the connection shows up as a key named after your app (
MCP · Your App). They can revoke it any time.
Who pays
The user, from their own Pikeway balance, at list price. Your balance is never touched.
Who owns the user
Shared. The user is your customer and also a Pikeway account holder: they top up, see usage and revoke access on Pikeway.
Good fit
- Agent apps and chat products where usage per user is unpredictable and you don't want to front the cost.
- MCP clients and IDE integrations. This is the same flow Claude.ai, ChatGPT and other remote MCP clients use to connect to
/mcp/agent. - Developer tools, notebooks and open-source projects whose users already have, or are happy to create, a Pikeway account.
- Free or low-price products that can't absorb per-call API costs.
Pros and cons
Pros
- Zero cost exposure: abuse and heavy users spend their own money, capped by the limit they chose.
- No billing to build: Pikeway handles top-ups, receipts and usage history for the user.
- Standard OAuth 2.1 with PKCE and dynamic client registration, so any OAuth library works and there's no client secret to protect.
- Users stay in control: they see exactly which apps are connected and can revoke one without affecting the rest.
Cons
- Extra step for users: they need a Pikeway account with a balance before your feature works.
- Pikeway is visible: users see the Pikeway consent page and Pikeway's prices.
- No markup: you can't add your own margin on top of each call. Charge for your product separately if you need revenue.
- Calls can fail at any time if the user's balance or limit runs out, or they revoke access. Your app must handle that gracefully.
What your app can and can't do
The consent page tells the user exactly this, so your product copy should match:
- Can: call any API or AI model on Pikeway, billed per call to the user's balance, up to the limit they chose.
- Can: see the user's account email or wallet address (via
/v1/auth/whoami) and their spendable balance. - Can't: withdraw funds, change account settings, or manage the user's own APIs or keys.
Compared with the other approaches
| Direct | Sign in with Pikeway | Your own proxy | |
|---|---|---|---|
| Who pays Pikeway | You, from your balance | Each user, from their own balance | You; you bill your users however you like |
| Owns the user relationship | You. Users never see Pikeway | Shared. Users have a Pikeway account and approve your app | You. Users never see Pikeway |
| User needs a Pikeway account | No | Yes | No |
| Your own pricing | Bundle the cost into your product | No: users pay Pikeway list prices | Yes: markup, credits, plans |
| Spend controls | Per-key limits, agent keys, IP allowlist | User picks a limit at consent; revocable any time | Your own rules, plus key limits as a backstop |
| What you run | Nothing extra: call from your backend | An OAuth client and token storage | A proxy service you operate |
| Time to first call | Minutes | About an hour | A day or more |
Rather keep Pikeway invisible?
Direct keeps everything on your key and your balance.
Need your own prices?
A proxy lets you charge users your way while you pay Pikeway.
Ready to build it? Continue to the setup guide.