DocHub
Tables, relationships, storage buckets, and RLS policies

Database Schema

All data lives in Supabase project foxuipkuotwhitlxssyc (Influencer Portal). This is a separate project from the main HypnoELP database.

Purpose

Store influencer profiles, group assignments, splash screen data, and link to Supabase Auth for portal authentication.

Tables

influencers

Primary table for all influencer/partner records.

Column Type Description
id UUID Primary key
created_at timestamp Auto-set on creation
updated_at timestamp Auto-updated
name text Influencer display name
email text Unique email address
code text Unique 7-character referral code (e.g., IK7MP3X)
auth_user_id UUID Foreign key to auth.users
splash_screen_url text URL of uploaded image in storage
splash_screen_status text null, pending, approved, or rejected
splash_screen_rejected_reason text Reason if rejected
splash_screen_html text Generated HTML with embedded base64 (set on approval)

groups

Content categories for organizing influencers.

Column Type Description
id UUID Primary key
name text Group name
description text Group description

7 predefined groups matching HypnoELP content categories.

influencer_groups

Junction table linking influencers to groups (many-to-many).

Column Type Description
influencer_id UUID FK → influencers.id
group_id UUID FK → groups.id

Storage

splash-screens bucket

Stores uploaded splash screen images. Public read access. Images are client-side compressed to ~100KB before upload (target: 1080x1920px, 9:16 aspect ratio).

RLS Policies

  • Influencers can only read their own record via auth_user_id = auth.uid()
  • Edge functions use the service role key to bypass RLS for admin operations
  • Storage bucket has public read, authenticated write

Data Model

auth.users (Supabase Auth)
    │
    └── influencers.auth_user_id
            │
            ├── influencer_groups.influencer_id ─── groups.id
            │
            └── splash-screens bucket (storage)