Agent skill · software engineering · insforge
insforge-integrations
Use when wiring an external auth provider (Clerk, Auth0, WorkOS, Kinde, Stytch, Better Auth) into InsForge for JWT-based RLS, or when adding the OKX x402 payment facilitator for onchain pay-per-use billing.
Why this skill is useful
Provides detailed integration patterns and specific setup instructions for multiple third-party auth and payment providers that the AI wouldn't reliably generate on its own.
What it needs
Requires auth0, better-auth, clerk, kinde, okx, stytch, workos account access. About 3k tokens when loaded. Last updated 2026-08-06. 36 stars on the source repository.
What this skill does
InsForge Integrations This skill covers integrating third-party providers with InsForge. Currently two categories are supported: auth providers (RLS via JWT claims) and payment facilitators (x402 HTTP payment protocol). Each provider has its own guide under this directory. Auth Providers Provider Guide When to use ---------- ------- ------------- Clerk Clerk JWT Templates + InsForge RLS Clerk signs tokens directly via JWT Template — no server-side signing needed Auth0 Auth0 Actions + InsForge RLS Auth0 uses a post-login Action to embed claims into the access token WorkOS WorkOS AuthKit + InsForge RLS WorkOS AuthKit middleware + server-side JWT signing with jsonwebtoken Kinde Kinde + InsForge RLS Kinde token customization for InsForge integration Stytch Stytch + InsForge RLS Stytch session tokens for InsForge integration Better Auth Better Auth + InsForge RLS Self-hosted auth running in your InsForge Postgres — no third-party SaaS, no per-MAU cost Payment Facilitators Provider Guide When to use ---------- ------- ------------- OKX x402 OKX as x402 facilitator (USDG on X Layer) Pay-per-use HTTP endpoints settled onchain with zero gas for the payer Common Patterns Auth providers 1. Provider signs or issues a JWT containing the user's ID 2. JWT is passed to InsForge via accessToken in createClient() (deprecated alias: edgeFunctionToken) 3. InsForge exposes claims through auth.jwt() in SQL 4. RLS policies use a requestinguserid() function to enforce row-level security Payment facilitators (x402) 1. Server returns 402 Payment Required with a JSON challenge base64-encoded in PAYMENT-REQUIRED header 2. Client signs an EIP-3009 authorization using the stablecoin's EIP-712 domain 3. Server forwards the signed payload to the facilitator's /verify + /settle endpoints 4. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills insforge/insforge-integrations