Webhook verification
Stripe and GitHub Sponsors webhook routes are part of the implementation and should be tested with provider signatures.
Technical Due Diligence
This page summarizes implementation status, security-conscious architecture, webhook handling, server-side AI calls, Supabase Auth, dashboard protection, test evidence, and known limitations.
Implementation status
The diligence posture is designed to help a buyer or senior developer review what exists without mistaking readiness for live customer proof.
Architecture
AgentFlow uses server-side provider calls, protected dashboard routing, Supabase Auth, webhook verification patterns, and buyer documentation as technical anchors.
Stripe and GitHub Sponsors webhook routes are part of the implementation and should be tested with provider signatures.
OpenAI credentials stay in server-side environment variables, with public demo boundaries separated from production writes.
Auth and session handling support protected workspace flows, backed by documentation for RLS and tenant review.
`proxy.ts` gates dashboard routes, while sensitive routes should continue to validate user and organization context server-side.
Evidence
The repository includes tests and documentation that give buyers something concrete to inspect before discussing acquisition or adoption.
Tests cover public demo validation, AI qualification, Stripe webhooks, and GitHub Sponsors webhook handling.
Docs cover environment variables, API behavior, Stripe webhooks, Supabase schema/RLS, billing lifecycle, integrations, and runbooks.
Known limitations are public so diligence can focus on real remaining work instead of marketing ambiguity.
Buyer checklist
A buyer should use this checklist before relying on AgentFlow for real customers, paid onboarding, or acquisition valuation.
Public docs
These public pages provide deeper technical context without exposing private dashboards, customer data, provider secrets, or internal credentials.
/docs
Environment variables, API behavior, webhooks, billing, integrations, and troubleshooting.
/security
Public-safe security language and operating boundaries for buyer review.
/business-trust
Trust posture, crawlability boundaries, billing controls, tenant isolation, and monitoring readiness.
FAQ
Each answer is written to preserve buyer confidence without inventing traction, certifications, or implementation proof that still needs verification.
No revenue validation is claimed. Buyers should treat it as a technical SaaS asset and validate the commercial motion separately.
No. The architecture and documentation are security-conscious, but no SOC 2, ISO, penetration test, SLA, or certification claim is made.
They should be treated as readiness paths unless a target deployment adds and verifies full UI and provider workflows.
Review path
Serious adoption or acquisition should be based on the current evidence and the buyer's verification plan.