Two silent failures that cost me days on Supabase (webhook JWT, RPC type mismatch)

[Lexitrm]

Building Bereah (AI Bible-study app) on Supabase. Two things failed silently before launch:

1. Webhook never reached my code. My Paystack webhook Edge Function was being rejected by the gateway JWT check on every call. Payment providers don't send a Supabase JWT, so with verify_jwt on, nothing got through. Fix: turn off gateway JWT verification for that function, authenticate the request myself, and pin verify_jwt per function in config.toml.
2. RPCs returning the wrong types. My email-lifecycle functions broke because of a varchar vs text mismatch between the function's return types and the real columns. Fix: explicit ::text casts and COALESCE.
   I also ran a security audit before launch (Security Advisor, RLS review, SECURITY DEFINER lockdown).
   Lesson: test the unauthenticated path end to end, and make sure a rejected request leaves a trace. How do you all handle webhook auth?

[cekuu35]

Your diagnosis on both is right, and the webhook one deserves a pattern answer since you asked.

On webhook auth (the general answer):

The Supabase gateway JWT check and payment-provider callbacks are fundamentally incompatible — no payment provider sends a Supabase-signed JWT, and it was never the right authenticator for that path. The correct pattern is what you landed on, made explicit:

1. verify_jwt = false for the webhook function only, pinned in config.toml (as you did) so it survives re-deploys.
2. Authenticate with the provider's own signature scheme — Paystack signs with x-paystack-signature (HMAC-SHA512 of the raw body with your secret key). The two details that silently break people: you must read the request body raw (a JSON body parser or any transformation before HMAC invalidates the signature), and you should reject on a timing-safe comparison.
3. Verify first, then authorize the event contents. Never the reverse.

On "a rejected request should leave a trace" — agreed, and the cheap fix is: when the signature check fails, log the raw body hash + headers (minus the signature) and return 401. Forged-traffic scanners probe payment webhooks constantly; a quiet 401 teaches you nothing, a logged one shows you the payload shape they're trying.

On the RPC type mismatch: the fix you found works, but the quieter root cause is worth naming — Postgres does not coerce return types between varchar and text in function returns even though they feel interchangeable in application code. Casting to the declared return type (::text) inside the function, as you did, is the durable fix; COALESCE for NULLs is a separate, complementary fix.

I keep running into the "unverified webhook" failure mode in code review — it survives because the handler looks complete (it parses, it acts, it returns 200). I built a small free linter for the Stripe flavor of exactly this class (raw-body requirements, missing constructEvent, hardcoded whsec): stripe-webhook-audit. The Paystack equivalent of the same rules applies by hand: signature header, raw body, constant-time compare.

Good pre-launch checklist discipline, by the way — Security Advisor + SECURITY DEFINER lockdown catches the loud stuff; the two failures you hit are the quiet stuff that only end-to-end unauthenticated-path testing finds.

[Lexitrm]

Thank you very much. This is a solid Analysis.