API Routes
The Next.js API surface backing tipping claims, IPFS pinning, and more.
LFG Pad's frontend is a Next.js app, and a handful of server-side routes exist specifically because they hold secrets or need Node-only APIs that must never ship to the client bundle.
POST /api/tipping/sign-claim
Given an OAuth-verified (platform, handle), signs the claim attestation digest described in Oracle Signing, authorizing claimerAddress to sweep that creator's tipping escrow on Robinhood Chain. Runs on the Node.js runtime (not Edge) since it needs viem/accounts' secp256k1 signer and an HTTP RPC read for the current nonce.
| Field | Type | Notes |
|---|---|---|
platform | string | Must be one of the configured tipping platform IDs. |
handle | string | Leading @ is stripped before hashing, matching the tipping UI's normalization. |
claimerAddress | 0x address | Where claimTips will pay out to. |
chainId | number | Robinhood Chain mainnet, 4663. The signature is bound to that chain's OmniTippingEscrow. |
accessToken | string (optional) | OAuth access token for platform — required unless the deployment has no oracle signer configured, in which case the route responds in a safe simulated demo mode instead of erroring. |
Note
When ORACLE_SIGNER_PRIVATE_KEY isn't configured on a given deployment, this route returns { simulated: true, signature: null } rather than throwing — the same 'explicit demo mode, not a silent failure' pattern used elsewhere in the app for unconfigured integrations.
Why these live server-side
- Secret custody —
ORACLE_SIGNER_PRIVATE_KEYmust never reach client-bundled code; only a server route can hold it. - Independent verification — OAuth access tokens are checked against the platform's own identity API server-side, so a compromised or spoofed client can't just assert a handle it doesn't control.
- Node-only dependencies — signing and RPC reads use APIs that either don't exist or don't behave identically on the Edge runtime.