This page documents the SMS consent flow used by BandGigz, a two-sided marketplace connecting live music venues with performing artists. It is published as a public reference for The Campaign Registry (TCR) and Twilio reviewers verifying our A2P 10DLC campaign registration. SMS notification consent is OPTIONAL and is not required to create or use a BandGigz account. No phone number is collected at signup; signup uses only email and password. A user who wants SMS notifications opts in after signup from Profile → Notifications, where they enter a phone number, receive a one-time verification code from Twilio Verify, and explicitly check a consent checkbox containing the verbatim disclosure shown in the "Canonical consent text" section below. To reproduce the flow yourself, click "Sign Up" on the homepage at https://bandgigz.com and select either Artist or Venue.
Signup itself collects only role (Artist or Venue), name, email, password, and agreement to the Terms of Service and Privacy Policy. No phone number is requested. No SMS-related disclosure appears on the signup form because the user is not opting in to SMS at this step.
The signup form has one required consent checkbox: Terms of Service / Privacy Policy. SMS is not mentioned on the signup form and no phone field is present.
The account is created via Supabase Auth and the user is sent an email confirmation link. At this point the user's profile has no phone number on file, phone_verified is false, and sms_consent is false. No SMS will ever be sent to this account in this state.
After confirming their email and logging in, a user who wants SMS notifications navigates to Profile → Notifications and starts the enrollment flow. The flow is a single modal with three views: phone entry, code entry plus the verbatim consent checkbox, and a success confirmation.
When no phone is on file, the Notifications section explains what SMS notifications are used for and offers a single Add phone number button. SMS cannot be enabled without explicitly starting this flow; there is no way to bypass it.
The user enters a US mobile number. Clicking Send code calls our JWT-authenticated sms-enroll-send-code Edge Function, which normalizes the number to E.164 format, checks that the number is not already verified on another account, and then calls Twilio Verify to send a 6-digit code via SMS. No SMS notifications are enabled at this step — only the one-time verification code is sent.
The user enters the 6-digit code Twilio Verify sent and must explicitly check the consent checkbox containing the verbatim canonical text shown in the next section. The Verify & Enable SMS button calls our sms-enroll-verify-and-opt-in Edge Function, which (1) verifies the code with Twilio Verify, (2) rejects the request if consentAccepted is not true in the request body, and only then (3) writes the phone number, verification timestamp + caller IP, and SMS consent state to the user's profile in a single atomic Postgres transaction. The transaction also appends an immutable row to our sms_consent_log audit table with the event type, phone number, caller IP, user-agent string, and timestamp.
On successful verification and write, the modal shows a success confirmation that reiterates what SMS messages the user will receive and that they can reply STOP at any time to opt out. This is the third place STOP is communicated in the flow (the canonical consent text in Step 5 is the second; the actual first SMS the user receives includes STOP language as required by carrier guidelines).
After enrollment, the Notifications section shows the verified phone number, the consent date, and an on/off toggle. The user can disable SMS from the same screen at any time (see "Turning SMS off" below).
The following text appears verbatim in the consent checkbox shown in Step 5 above. It is stored as a single non-editable constant in the frontend code and is the only place SMS consent is collected in the BandGigz product:
"By confirming this phone number, you agree to receive SMS text messages from BandGigz about your account activity — including booking applications, payment receipts, gig confirmations, dispute updates, and security alerts. Message frequency varies based on account activity. Message and data rates may apply. Reply STOP to opt out at any time, or HELP for help. BandGigz does not sell, rent, share, or otherwise disclose your mobile phone number or SMS opt-in status to any third party or affiliate for marketing, promotional, or advertising purposes. You can disable SMS notifications anytime from your account settings."
A user who has enabled SMS can disable it at any time through any of the following paths. Each path produces an audit log entry in the sms_consent_log table.
The user toggles the SMS switch off in the Notifications section. This calls the JWT-authenticated update-sms-consent Edge Function, which atomically writes sms_consent=false to the profile and appends an opted_out_user row to sms_consent_log with source profile_settings. The original consent timestamp and IP are preserved as audit history of when the user first consented. The user can re-enable SMS at any time from the same toggle without re-verifying their phone — their existing verification is honored.
Replying STOP, STOPALL, UNSUBSCRIBE, CANCEL, END, or QUIT to any BandGigz SMS triggers our sms-inbound webhook (HMAC-SHA1 signature verified against Twilio). The webhook (1) flips sms_opted_out=true on every profile matching the sending phone number, (2) adds the phone number to our phone-level suppression table so future sends are blocked at the source, (3) appends an opted_out_stop_keyword row to sms_consent_log with source inbound_sms, and (4) replies with the standard unsubscribe confirmation. Replying HELP or INFO at any time returns support contact information and a reminder of how to opt out.
A user who replied STOP can resubscribe by replying START, UNSTOP, or YES to a BandGigz SMS. Our sms-inbound webhook flips sms_opted_out=false on profiles matching that number, removes the phone from the suppression table, and appends a re_subscribed_start_keyword row to sms_consent_log. The user's sms_consent state is not changed by START — it remains at whatever they last set in the UI. If they had also disabled the UI toggle, they will need to re-enable that toggle in Notifications to actually resume receiving SMS. This two-key approach (carrier-level STOP/START versus app-level consent toggle) prevents a user who deliberately turned SMS off in the UI from being inadvertently re-opted-in by replying START to an old message.
The user's current SMS consent state lives on the profiles row in our Supabase database across the following columns: phone (E.164 string), phone_verified (boolean, set to true only after successful Twilio Verify), phone_verified_at (timestamp of verification), phone_verified_ip (caller IP at the time of verification), sms_consent (boolean reflecting the user's current opt-in state in the UI), sms_consent_at (timestamp of last opt-in event), sms_consent_ip (caller IP at the time of last opt-in), sms_opted_out (boolean for carrier-level STOP state), and sms_opted_out_at (timestamp of last STOP event). All SMS-related profile columns are protected by a database trigger (trg_prevent_sms_client_writes) that blocks any non-service-role connection from modifying them; browser code cannot bypass the gate. The columns are flipped only by our sms-enroll-verify-and-opt-in, update-sms-consent, and sms-inbound Edge Functions, all of which write through the service-role client.
Every consent state change — whether enrollment, UI-initiated opt-out, STOP keyword opt-out, or START keyword resubscription — also writes an immutable row to our append-only sms_consent_log audit table. Each row records the user, event type, phone number, caller IP, user-agent string, source (profile_settings or inbound_sms), and timestamp. The audit log is service-role only (zero RLS policies) and is the authoritative history of consent events for any individual user.
Every A2P SMS attempted by our send-notification Edge Function is gated by a four-condition check on the recipient's profile: phone IS NOT NULL, phone_verified=true, sms_consent=true, and sms_opted_out=false. If any condition fails, the SMS is silently skipped and the user receives the email-only transactional notification. This gate runs on every send and is the runtime enforcement of the consent state recorded in the columns above. Twilio Verify codes (the one-time verification message during enrollment) are sent through a separate channel and bypass this gate because Twilio Verify is documented by Twilio as exempt from A2P 10DLC consent rules.
sms-inbound webhook with HMAC-SHA1 signature verification.Opting out does not affect access to the account; users continue to receive transactional email via Resend. Full SMS Program Terms are at https://bandgigz.com/terms.html Section 6.5.
BandGigz does not sell, rent, share, or otherwise disclose mobile phone numbers, SMS opt-in status, or SMS consent records to any third party or affiliate for marketing, promotional, or advertising purposes. Mobile information is shared only with our SMS provider (Twilio) and only to the extent required to deliver notifications a user has opted into. This commitment is also stated in our Privacy Policy and in our SMS Program Terms (Section 6.5 of the Terms of Service).
For questions about this consent flow or the BandGigz SMS program, contact bandgigzpro@gmail.com.
Updated May 18, 2026: restructured for the new post-signup enrollment architecture. Phone collection moved from signup to a dedicated opt-in flow in Profile → Notifications, with a verbatim consent checkbox at the moment of opt-in. Added the sms_consent_log audit trail and documented the canonical consent text as a single source of truth.