insforge-integrations

Name: insforge-integrations
Author: InsForge

252installs11forks

How to install insforge-integrations?

insforge/insforge-skills/insforge-integrations

$npx -y skills add InsForge/insforge-skills --skill insforge-integrations

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# InsForge Integrations
2
3	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.
4
5	## Auth Providers
6
7	\| Provider \| Guide \| When to use \|
8	\|----------\|-------\|-------------\|
9	\| [Clerk](references/clerk.md) \| Clerk JWT Templates + InsForge RLS \| Clerk signs tokens directly via JWT Template — no server-side signing needed \|
10	\| [Auth0](references/auth0.md) \| Auth0 Actions + InsForge RLS \| Auth0 uses a post-login Action to embed claims into the access token \|
11	\| [WorkOS](references/workos.md) \| WorkOS AuthKit + InsForge RLS \| WorkOS AuthKit middleware + server-side JWT signing with `jsonwebtoken` \|
12	\| [Kinde](references/kinde.md) \| Kinde + InsForge RLS \| Kinde token customization for InsForge integration \|
13	\| [Stytch](references/stytch.md) \| Stytch + InsForge RLS \| Stytch session tokens for InsForge integration \|
14	\| [Better Auth](references/better-auth.md) \| Better Auth + InsForge RLS \| Self-hosted auth running in your InsForge Postgres — no third-party SaaS, no per-MAU cost \|
15
16	## Payment Facilitators
17
18	\| Provider \| Guide \| When to use \|
19	\|----------\|-------\|-------------\|
20	\| [OKX x402](references/okx-x402.md) \| OKX as x402 facilitator (USDG on X Layer) \| Pay-per-use HTTP endpoints settled onchain with zero gas for the payer \|
21
22	## Common Patterns
23
24	### Auth providers
25	1. Provider signs or issues a JWT containing the user's ID
26	2. JWT is passed to InsForge via `accessToken` in `createClient()` (deprecated alias: `edgeFunctionToken`)
27	3. InsForge exposes claims through `auth.jwt()` in SQL
28	4. RLS policies use a `requesting_user_id()` function to enforce row-level security
29
30	### Payment facilitators (x402)
31	1. Server returns `402 Payment Required` with a JSON challenge base64-encoded in `PAYMENT-REQUIRED` header
32	2. Client signs an EIP-3009 authorization using the stablecoin's EIP-712 domain
33	3. Server forwards the signed payload to the facilitator's `/verify` + `/settle` endpoints
34	4. Server records the settled payment in an InsForge table with a realtime trigger for live dashboards
35
36	## Choosing a Provider
37
38	Auth
39	- Clerk — Simplest setup; JWT Template handles signing, no server code needed
40	- Auth0 — Flexible; uses post-login Actions for claim injection
41	- WorkOS — Enterprise-focused; AuthKit middleware + server-side JWT signing
42	- Kinde — Developer-friendly; built-in token customization
43	- Stytch — API-first; session-based token flow
44	- Better Auth — Self-hosted in your Postgres; no SaaS vendor; you own the user table. Pairs cleanly with InsForge's Postgres via a connection string + a small bridge route. Requires a one-time `REVOKE` after migrate to seal PostgREST exposure.
45
46	Payment facilitators
47	- OKX x402 — Onchain pay-per-use via USDG on X Layer; zero gas for the payer
48
49	## Setup
50
51	1. Identify which provider the project uses
52	2. Read the corresponding reference guide from the tables above
53	3. Follow the provider-specific setup steps
54
55	## Usage Examples
56
57	Each provider guide includes full code examples for:
58	- Provider dashboard configuration (API keys, application settings, etc.)
59	- Server and client code (JWT utilities for auth; facilitator client + signing utilities for payments)
60	- Database setup (RLS for auth; payment table + realtime trigger for payments)
61	- Environment variable setup
62
63	Refer to the specific `references/<provider>.md` file for complete examples.
64
65	## Best Practices
66
67	Auth
68	- All auth provider user IDs are strings (not UUIDs) — always use `TEXT` columns for `user_id`
69	- Use `requesting_user_id()` instead of `auth.uid()` for RLS policies
70	- Pass the JWT via `accessToken` — a static string, not a function; for short-lived tokens (Clerk) sync refreshes with `client.setAccessToken(token, AuthChangeEvent.TOKEN_REFRESHED)` after the initial same-user sign-in
71	- Always get the JWT secret via `npx @insforge/cli secrets get JWT_SECRET`
72
73	Payment facilitators (x402)
74	- Always check the result of the database `insert(...)` after settlement — settlement takes money onchain before the insert runs; a silent DB failure loses the record
75	- Add `UNIQUE` to the `tx_hash` column to prevent duplicate records from retries
76	- Verify EIP-712 domain (`name`, `version`) against the token contract's on-chain `DOMAIN_SEPARATOR` — wrong values produce `Invalid Authority` errors
77	- Use a `MOCK_OKX_FACILITATOR` env flag for local dev so the full flow can be exercised without real funds
78
79	## Common Mistakes
80
81	Auth
82
83	\| Mistake \| Solution \|
84	\|---------\|----------\|
85	\| Using `auth.uid()` for RLS \| Use `requesting_u

People who liked this also viewed

6 picks

Type

insforge-integrations

252installs11forks

View on GitHub

How to install insforge-integrations?

insforge/insforge-skills/insforge-integrations

$npx -y skills add InsForge/insforge-skills --skill insforge-integrations

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# InsForge Integrations
2
3	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.
4
5	## Auth Providers
6
7	\| Provider \| Guide \| When to use \|
8	\|----------\|-------\|-------------\|
9	\| [Clerk](references/clerk.md) \| Clerk JWT Templates + InsForge RLS \| Clerk signs tokens directly via JWT Template — no server-side signing needed \|
10	\| [Auth0](references/auth0.md) \| Auth0 Actions + InsForge RLS \| Auth0 uses a post-login Action to embed claims into the access token \|
11	\| [WorkOS](references/workos.md) \| WorkOS AuthKit + InsForge RLS \| WorkOS AuthKit middleware + server-side JWT signing with `jsonwebtoken` \|
12	\| [Kinde](references/kinde.md) \| Kinde + InsForge RLS \| Kinde token customization for InsForge integration \|
13	\| [Stytch](references/stytch.md) \| Stytch + InsForge RLS \| Stytch session tokens for InsForge integration \|
14	\| [Better Auth](references/better-auth.md) \| Better Auth + InsForge RLS \| Self-hosted auth running in your InsForge Postgres — no third-party SaaS, no per-MAU cost \|
15
16	## Payment Facilitators
17
18	\| Provider \| Guide \| When to use \|
19	\|----------\|-------\|-------------\|
20	\| [OKX x402](references/okx-x402.md) \| OKX as x402 facilitator (USDG on X Layer) \| Pay-per-use HTTP endpoints settled onchain with zero gas for the payer \|
21
22	## Common Patterns
23
24	### Auth providers
25	1. Provider signs or issues a JWT containing the user's ID
26	2. JWT is passed to InsForge via `accessToken` in `createClient()` (deprecated alias: `edgeFunctionToken`)
27	3. InsForge exposes claims through `auth.jwt()` in SQL
28	4. RLS policies use a `requesting_user_id()` function to enforce row-level security
29
30	### Payment facilitators (x402)
31	1. Server returns `402 Payment Required` with a JSON challenge base64-encoded in `PAYMENT-REQUIRED` header
32	2. Client signs an EIP-3009 authorization using the stablecoin's EIP-712 domain
33	3. Server forwards the signed payload to the facilitator's `/verify` + `/settle` endpoints
34	4. Server records the settled payment in an InsForge table with a realtime trigger for live dashboards
35
36	## Choosing a Provider
37
38	Auth
39	- Clerk — Simplest setup; JWT Template handles signing, no server code needed
40	- Auth0 — Flexible; uses post-login Actions for claim injection
41	- WorkOS — Enterprise-focused; AuthKit middleware + server-side JWT signing
42	- Kinde — Developer-friendly; built-in token customization
43	- Stytch — API-first; session-based token flow
44	- Better Auth — Self-hosted in your Postgres; no SaaS vendor; you own the user table. Pairs cleanly with InsForge's Postgres via a connection string + a small bridge route. Requires a one-time `REVOKE` after migrate to seal PostgREST exposure.
45
46	Payment facilitators
47	- OKX x402 — Onchain pay-per-use via USDG on X Layer; zero gas for the payer
48
49	## Setup
50
51	1. Identify which provider the project uses
52	2. Read the corresponding reference guide from the tables above
53	3. Follow the provider-specific setup steps
54
55	## Usage Examples
56
57	Each provider guide includes full code examples for:
58	- Provider dashboard configuration (API keys, application settings, etc.)
59	- Server and client code (JWT utilities for auth; facilitator client + signing utilities for payments)
60	- Database setup (RLS for auth; payment table + realtime trigger for payments)
61	- Environment variable setup
62
63	Refer to the specific `references/<provider>.md` file for complete examples.
64
65	## Best Practices
66
67	Auth
68	- All auth provider user IDs are strings (not UUIDs) — always use `TEXT` columns for `user_id`
69	- Use `requesting_user_id()` instead of `auth.uid()` for RLS policies
70	- Pass the JWT via `accessToken` — a static string, not a function; for short-lived tokens (Clerk) sync refreshes with `client.setAccessToken(token, AuthChangeEvent.TOKEN_REFRESHED)` after the initial same-user sign-in
71	- Always get the JWT secret via `npx @insforge/cli secrets get JWT_SECRET`
72
73	Payment facilitators (x402)
74	- Always check the result of the database `insert(...)` after settlement — settlement takes money onchain before the insert runs; a silent DB failure loses the record
75	- Add `UNIQUE` to the `tx_hash` column to prevent duplicate records from retries
76	- Verify EIP-712 domain (`name`, `version`) against the token contract's on-chain `DOMAIN_SEPARATOR` — wrong values produce `Invalid Authority` errors
77	- Use a `MOCK_OKX_FACILITATOR` env flag for local dev so the full flow can be exercised without real funds
78
79	## Common Mistakes
80
81	Auth
82
83	\| Mistake \| Solution \|
84	\|---------\|----------\|
85	\| Using `auth.uid()` for RLS \| Use `requesting_u

People who liked this also viewed

6 picks

Type