Supabase Edge Functions Overview

Relevant source files

The following files were used as context for generating this wiki page:

• supabase/functions/federation-state/index.ts
• supabase/functions/dashboard-summary/index.ts
• supabase/functions/protocols-execute/index.ts
• supabase/functions/places-register/index.ts
• supabase/functions/github-sync/index.ts
• supabase/functions/isabella-evaluate/index.ts
• supabase/functions/stripe-webhook/index.ts

Introduction

Supabase Edge Functions serve as the serverless backend layer for the RDM Digital / TAMV Online platform. These functions handle critical business logic, integration with external services like GitHub and Stripe, and enforcement of governance protocols through the Isabella evaluation engine.

Operating within a Deno environment, these functions interact directly with the Supabase database and authentication services to manage telemetry, billing, repository synchronization, and dashboard state. Sources: README.md, supabase/functions/protocols-execute/index.ts

Core Architecture and Shared Logic

The Edge Functions follow a consistent structure for request handling, including CORS validation, user authentication, and service role client initialization. Most functions identify their own purpose by parsing the URL path.

Request Flow and Security

Requests are processed through a central Deno.serve handler. Security is enforced through two primary mechanisms:

1. JWT Validation: The requireUser helper validates Bearer tokens against Supabase Auth.
2. Role-Based Access: Certain functions, such as github-sync, require an admin role checked via a database RPC call (has_role).
3. Signature Verification: Webhooks (e.g., Stripe) utilize secret-based signature validation instead of standard JWTs.

Sources: supabase/functions/protocols-execute/index.ts:5-20, supabase/functions/github-sync/index.ts:5-14

The diagram above illustrates the multi-tiered authentication logic implemented across the edge function suite. Sources: supabase/functions/protocols-execute/index.ts:22-68, supabase/functions/github-sync/index.ts:16-24

Functional Modules

1. Data Aggregation and State

Endpoints like federation-state and dashboard-summary provide read-only access to system-wide metrics. These are classified as PUBLIC_READ.

• federation-state: Returns exact counts for federations, core repositories, and protocol executions.
• dashboard-summary: Returns counts of active businesses and core repositories, alongside a kernel identifier (TAMV/MD-X4).

Sources: supabase/functions/federation-state/index.ts:31-48, supabase/functions/dashboard-summary/index.ts:41-47

2. External Integration (GitHub & Stripe)

Edge functions automate the synchronization of the project's "Evolutionary Repository" and handle financial transactions.

• github-sync: Authenticated admins can trigger a sync that fetches data from the GitHub API, classifies repositories into federations, and upserts them into the repositories table.
• stripe-checkout: Generates checkout sessions for business subscriptions.
• stripe-webhook: Listens for asynchronous payment events to update business statuses.

Sources: supabase/functions/github-sync/index.ts:26-65, supabase/functions/stripe-checkout/index.ts:60-63

3. Governance and Evaluation (Isabella)

The isabella-evaluate function acts as a security and protocol gatekeeper. It analyzes payloads for malicious patterns (e.g., malware, scraping tools) and assigns a decision (accept, alert, or reject).

• Logic: Uses regex-based pattern matching on the request body.
• Persistence: Decisions are logged in protocol_executions and bookpi_entries with SHA-256 hashes and digital signatures.

Sources: supabase/functions/isabella-evaluate/index.ts:18-35

This sequence shows how the Isabella evaluation engine validates actions and records them in the immutable ledger. Sources: supabase/functions/isabella-evaluate/index.ts:21-34

API Endpoint Summary

Endpoint	Auth Required	Purpose	Primary Data Source
federation-state	No	System-wide counts of federations and executions	federations, protocol_executions
dashboard-summary	No	Summary of active businesses and core repos	businesses, repositories
github-sync	Admin	Synchronize GitHub repository metadata	GitHub API -> repositories
isabella-evaluate	User	Security evaluation and protocol logging	Request Body -> bookpi_entries
telemetry-ingest	User	Ingestion of operational data	Request Body -> analytics
stripe-webhook	Signature	Process asynchronous Stripe events	Stripe SDK -> businesses

Sources: supabase/functions/protocols-execute/index.ts:25-75, supabase/functions/github-sync/index.ts:16-18, supabase/functions/isabella-evaluate/index.ts:18-20

Implementation Details: Telemetry and Analytics

Generic functions (like telemetry-ingest or any function not explicitly handled by specific logic) default to an analytics ingestion pattern. This pattern validates the payload size (maximum 10,000 characters) before inserting it into the analytics table.

// Payload validation before insertion
const safeBody = typeof body === "object" && body !== null ? body : {}
const serialized = JSON.stringify(safeBody)
if (serialized.length > 10000) return json({ error: "payload too large" }, 413)

await supabase.from("analytics").insert({ event_type: functionName, data: safeBody })

Sources: supabase/functions/telemetry-ingest/index.ts:65-71

Conclusion

Supabase Edge Functions in RDM Digital provide a robust, event-driven architecture that bridges the gap between the static frontend and dynamic external ecosystems. By centralizing security checks, protocol evaluation (via Isabella), and data normalization (via GitHub Sync), the system ensures that all server-side operations remain auditable and secure.