Skip to main content
Google Forms is an intake channel only. Supabase remains the system of record, and Resend continues to deliver verification, approval, denial, usage, revocation, and management emails.

Form questions

Create a form that does not require a Google account and add these question titles exactly: Test access should be described as non-expiring, limited development and early-stage access. Production access should be described as a paid capacity review.

Connect the form

  1. Open the form’s Apps Script project.
  2. Paste integrations/google-forms/Code.gs into the project.
  3. In Project Settings → Script Properties, add:
    • HFSAA_INGEST_URL: the target Worker’s URL ending in /v1/integrations/google-forms/applications.
    • HFSAA_INGEST_TOKEN: a dedicated random ingestion secret. Never use the administrator token.
  4. Run installFormSubmitTrigger once and approve the requested Google permissions.
  5. Link responses to a restricted Google Sheet for operational review. Limit Sheet and Script access to HFSAA administrators.
The trigger sends each response to the Worker. The Worker validates the dedicated secret, stores the request in Supabase, and asks Resend to verify the applicant’s email. Retries use a deterministic verification token and Resend idempotency key, so a repeated trigger does not create multiple active applications or different verification links.

Staging verification

Submit a test response using an HFSAA-controlled inbox. Confirm that:
  1. The form response appears in the restricted Sheet.
  2. The Worker returns HTTP 202 to Apps Script.
  3. The verification email arrives through Resend.
  4. Clicking the verification link moves the Supabase application to pending_review.
  5. The application appears in the HFSAA admin dashboard.
Do not connect the production Worker until the staging flow passes end to end.

Production intake

For the MVP, use one public form as the production intake after the staging flow has passed. Keep its existing authorized onFormSubmit trigger, create a new production ingestion token, and update the bound script properties to:
  • HFSAA_INGEST_URL: https://hfsaa-public-api.idris-ocasio.workers.dev/v1/integrations/google-forms/applications
  • HFSAA_INGEST_TOKEN: the production Worker’s dedicated GOOGLE_FORMS_INGEST_TOKEN value
Publish the form without requiring a Google account and set the production Worker’s DEVELOPER_APPLICATION_FORM_URL variable to its responder URL. New applications then enter the production review queue. Approved test keys still use the staging API base URL, while approved production keys use https://hfsaa-public-api.idris-ocasio.workers.dev. Run a controlled HFSAA-owned test submission before sharing the form publicly. If a separately isolated staging intake is needed later, copy the form and script and give that copy its own staging-only ingestion token.

Recovery while the custom domain is unavailable

The October 2026 outage affected api.hfsaa.org; the production Worker remained reachable at https://hfsaa-public-api.idris-ocasio.workers.dev. While the custom domain is being repaired, use that production Worker for both the form’s HFSAA_INGEST_URL and the Worker’s PUBLIC_API_BASE_URL. Updating both keeps verification, claim, management, and administrator links reachable. Keep the existing production ingestion secret and the staging URL. Add integrations/google-forms/Recovery.gs alongside Code.gs. Run enableProductionRecoveryEndpoint to verify production health and the existing ingestion secret before changing the form URL. It saves the previous URL in HFSAA_PRE_RECOVERY_INGEST_URL. Run checkIntakeConnection for subsequent checks. These functions send an empty payload that must return 400 invalid_application after authentication; they do not create applications or send verification emails. The old DNS zone used cullen.ns.cloudflare.com and iris.ns.cloudflare.com. Cloudflare’s October 4 alert detected a move to sullivan.ns.cloudflare.com and ulla.ns.cloudflare.com; the old zone was deleted October 11. Identify the administrator of the current authoritative DNS account before restoring the custom domain. Preserve the working website and mail records. After https://api.hfsaa.org/health returns the production health response, restore both URL settings together and run checkIntakeConnection again. The form retains submitted responses even when its trigger fails. Review failed executions and the retained responses before retrying specific submissions; a retry may send the applicant a verification email. The recovery checks do not replay submissions. replayFailedOctoberApplications is prepared for the two reviewed October 24–26 submissions and must be run only after approving those verification emails. It refuses an unexpected response count and records each successful replay so a later run skips completed submissions. Resend’s developers.hfsaa.org sending domain also lost its required DKIM and SPF records. Restore the records shown in Resend’s domain settings in the current authoritative DNS zone, then restart domain verification. Until the domain verifies, automatic application, approval, and management emails remain unavailable. For the two authorized October recovery emails, prepareManualOctoberVerificationEmails persists each application and prepares the same deterministic verification link used by the Worker. Links are temporarily kept in HFSAA_OCTOBER_MANUAL_EMAILS in Script Properties and never logged. Before sending through the HFSAA mailbox, confirm each prepared token hash matches its saved application’s verification_token_hash and the application still requires email verification. After both messages appear in Sent, run completeManualOctoberVerificationRecovery to mark those responses complete and remove the temporary links. Do not rerun preparation after sending: it may refresh the expiry of an existing link.