WhatsApp

WhatsApp Cloud API Setup for Google Forms

Prepare customer-owned Meta development assets, test numbers, recipients, tokens, approved templates, and FormBeacon mappings without exposing private identifiers.

Published · Updated · 17 min read

Connect customer-owned Meta sandbox resources

Business customers provide their own Meta WhatsApp Business Platform account, app, WhatsApp Business Account, test or sending number, phone-number ID, access token, recipient authorization, and approved template. Meta's official WhatsApp Cloud API collection is Meta's official Cloud API collection. FormBeacon subscription fees do not include Meta usage charges; applicable Meta fees stay in the customer's Meta account.

Meta's official Postman collection demonstrates the Cloud API request and component model. Where direct developer pages were unavailable, this guide infers the setup shape from those official examples. FormBeacon's approved-status, exact-language, declared-slot, fixed-origin, and no-arbitrary-JSON rules are stricter product policy, not claims about additional Meta API requirements.

Local synthetic fixture
Template: job_application_review
Language: en_US
Body slot 1: Avery Example
Dynamic URL suffix: SYN-1042

This compact mapping is a local FormBeacon example, not evidence that Meta approved a template or delivered a message. The exact provider-approved template identity, language, components, and status remain authoritative at send time.

  1. 1Create or select a development-only Meta app and add WhatsApp without touching unrelated production apps.
  2. 2Confirm the test WABA, test number, recipient allowlist, token, and phone-number ID in Meta's setup surface.
  3. 3Enter secrets only into masked FormBeacon fields and keep all identifiers out of screenshots and article examples.
  4. 4Sync safe template metadata, then select an approved template and exact language.
  5. 5Send once to the approved synthetic recipient and distinguish API acceptance from recipient-visible delivery.

Prepare the Meta assets in the right order

This article focuses on the provider-side configuration that must be correct before a form notification can be trusted. Prepare a development-only Meta app, test WhatsApp Business Account, test number, allowlisted recipient, token, phone-number ID, and approved template for one controlled FormBeacon send.

Meta's official WhatsApp Cloud API collection is Meta's official Cloud API collection and documents the send-oriented asset and request model.

Customers provide their own Meta account and credentials. Applicable Meta fees remain in their Meta account and are separate from the FormBeacon subscription.

Map the Meta business assets before issuing a token

The practical goal is Prepare a development-only Meta app, test WhatsApp Business Account, test number, allowlisted recipient, token, phone-number ID, and approved template for one controlled FormBeacon send. A notification becomes useful only when a named person knows what to do after it arrives. Before changing the form, record the form owner, the destination owner, who may see the submitted information, and the action expected from the first reader.

For WhatsApp Cloud API setup, keep Google Forms as the response system of record. FormBeacon delivers a notification; it is not a CRM, ticket database, applicant-tracking system, booking engine, or conditional workflow builder. If the process needs assignment state, approvals, capacity enforcement, scheduled reminders, or answer-based branching, keep those controls in a suitable system and use the message as the prompt to act.

DecisionRecord before setupWhy it matters
Form ownershipOne durable Google account that can edit the formThe installable submit trigger belongs to the account that creates it
Destinationthe configured WhatsApp recipient numberA technically successful delivery to the wrong room is still a privacy and operations failure
AudienceOnly people who need the submitted dataThe provider retains and displays the delivered message under its own controls
First actionA concrete acknowledgement, reply, review, or follow-upAlerts without an owner quickly become background noise
FallbackHow the team checks Google Forms when delivery is unavailableThe notification should not become the only way to find a response

When rehearsing WhatsApp Cloud API setup, use a copied form and a private test destination. Enter obviously fictional answers. That keeps setup separate from real personal, customer, health, hiring, or payment-related information and makes it safe to repeat tests while permissions are being corrected.

Choose the exact asset, owner, and permission model

QuestionRecommended starting pointTrade-off
Who owns Meta assets?The customerCredentials and provider fees remain in their account
Development or production?Development/test resources for setupProduction rollout needs separate approval
Free-form message?No, approved template onlyBusiness does not expose arbitrary WhatsApp JSON
Acceptance or receipt?Verify both separatelyA provider message ID is not visible-delivery proof

1. Use a development-only app

Create or select a sandbox app connected to the intended Meta business portfolio. Do not reuse or mutate unrelated production apps.

Meta dashboard for the unpublished FormBeacon Sandbox WhatsApp development app
The FormBeacon Sandbox dashboard shows its WhatsApp use-case customization and test checks while Publish remains Unpublished. This does not prove publication or message delivery.Open full-size screenshot ↗

2. Add WhatsApp

Open WhatsApp setup and identify the test WABA, test number, and phone-number ID without copying values into screenshots or notes.

Meta WhatsApp Test Number showing Connected status and High quality
The FormBeacon Sandbox Test WABA shows its customer-visible Test Number identity as Connected with High quality. The phone number and private Meta identifiers are excluded, and this state does not prove template approval or message delivery.Open full-size screenshot ↗

3. Authorize a test recipient

Add only a number you control and complete Meta's verification flow. Keep phone numbers and OTPs out of captures.

4. Obtain a bounded token

Use Meta's development credential for the sandbox send. Paste it only into FormBeacon's masked credential field.

5. Sync template metadata

Fetch safe template name, language, status, components, and declared slots; do not retain raw provider responses.

6. Select an approved template

Choose the exact approved identity and language. Pending, rejected, paused, or disabled templates fail closed.

7. Map declared slots

Map stable form or response variables only to header, body, and dynamic URL-button slots declared by Meta.

8. Send and verify once

Run one synthetic test, record only redacted acceptance metadata, and separately confirm recipient-visible receipt.

Verify each Meta identifier before sending a template

To accept WhatsApp Cloud API setup, run both a saved configuration test and a real form submission because they answer different questions. The saved test checks whether the current credential, destination, and message can reach the provider. A real submission additionally checks the Google trigger, form binding, response rendering, and delivery path. Both results must succeed.

  1. 1Create a private test destination or tell the intended channel that a harmless test is coming.
  2. 2Use a copied form with short fictional values, including one blank optional answer and one value containing punctuation.
  3. 3Save the simplest supported mode first. Do not begin with a complex provider-specific Advanced structure.
  4. 4Run the destination test and confirm an accepted template message at the intended WhatsApp number.
  5. 5Open the public responder view of the copied Google Form and submit it like a respondent would.
  6. 6Confirm that exactly one new message appears, that the form title and submission time are plausible, and that the message is visible only to the intended audience.
  7. 7Repeat once with a multiline answer and non-ASCII text. This catches formatting assumptions that a one-word test will miss.
  8. 8Return to the add-on and review the visible delivery status without pasting credentials into a support conversation.

When checking WhatsApp Cloud API setup, a working saved test and a failed real submission point to trigger ownership, Google authorization, the selected form, or event eligibility. If neither works, inspect the destination credential and provider permissions first. If delivery succeeds but the content is hard to read, keep the credential unchanged and simplify the template. Changing one layer at a time preserves evidence.

ObservationMost useful interpretationNext check
Saved test failsProvider credential, destination, configuration, or entitlement problemRe-enter the credential privately and verify provider-side access
Saved test succeeds; form submission does notGoogle trigger, authorization, form binding, or event problemReopen the add-on as the trigger owner and inspect status
One submission creates two messagesMore than one active trigger or destination may existInspect active destinations and remove duplicate trigger ownership intentionally
Message arrives in the wrong roomThe credential points to a different destinationCreate or select the credential from the exact target destination
Basic works; Advanced failsThe provider-specific Advanced structure is invalidUse the provider validator and reintroduce fields one at a time

If WhatsApp Cloud API setup still fails, use the provider-by-provider Google Forms notifications diagnostic guide. Record the test time, form name, destination name, and redacted error code. Never record submitted answers or the secret itself in a shared incident note.

Diagnose WhatsApp credential and permission failures

SymptomLikely causeWhat to do next
Authentication rejectedToken expired, revoked, or lacks asset accessReplace it privately through Meta
Template unavailableStatus, name, language, or WABA mismatchSync metadata and select an approved exact match
Recipient rejectedNumber is not authorized in the test setupComplete Meta recipient verification
Accepted but not visibleProvider acceptance is not receiptInspect the authorized test phone once and retain redacted evidence

How FormBeacon uses the phone-number ID and access token

In WhatsApp Cloud API setup, Google invokes a user-owned installable form-submit trigger after configuration. The add-on reads the submitted response, renders the selected message, and sends it to FormBeacon's delivery API. The service applies plan limits and idempotency, uses the encrypted destination configuration to call the selected provider, and stores redacted delivery metadata rather than submitted answer content or rendered notification bodies.

That architecture is the diagnostic map for WhatsApp Cloud API setup. FormBeacon is not a direct browser-to-webhook shortcut, and it does operate a delivery service. At the same time, response answers do not become a searchable FormBeacon database. Google Forms remains the record you inspect or correct; the provider receives the message you explicitly send; FormBeacon retains only the bounded configuration and redacted operational data required to deliver and diagnose it.

  1. 1A respondent submits the Google Form and Google records the response.
  2. 2The verified form owner’s installable trigger runs for that submission.
  3. 3The add-on prepares a request containing the form and response references needed for delivery.
  4. 4FormBeacon validates identity, form entitlement, quota, destination configuration, and idempotency.
  5. 5The service calls the provider using a Meta access token, WhatsApp phone-number ID, approved template, language, and destination number.
  6. 6On success, the service records redacted success metadata and counts one successful outbound destination delivery as one notification.
  7. 7On failure, the failed attempt does not consume the Free successful-delivery quota; an idempotent retry must not count the same delivery twice.

Before publishing WhatsApp Cloud API setup, check provider behavior against Meta's WhatsApp Cloud API collection, because provider interfaces, permissions, limits, and policy wording can change. Check FormBeacon's product behavior and prices on the pricing page and in the current add-on rather than inferring them from an old screenshot.

Rotate and protect the WhatsApp credential

For WhatsApp Cloud API setup, treat the Meta access token as a production credential. Store it only in the destination configuration, restrict who can administer the Meta business assets, and replace it through Meta if it is exposed.

Every delivery created by WhatsApp Cloud API setup is a new copy of the notification. Google Form sharing does not automatically restrict a Slack channel, Discord channel, Telegram group, WhatsApp recipient, or webhook receiver. Before choosing Insert all fields, review every form question and assume every destination member can read the rendered values. For sensitive workflows, send a minimal reference and instruct authorized staff to open Google Forms rather than copying all answers into a notification.

  • Use the narrowest private destination that still supports the workflow.
  • Remove webhook URLs, bot tokens, access tokens, and real phone numbers from screenshots and screen recordings.
  • Do not submit real customer or employee data while testing.
  • Review provider retention, export, moderation, and member-access settings separately from FormBeacon.
  • Rotate an exposed credential at the provider, update FormBeacon, and run both tests again.
  • Delete test messages that contain even fictional data if they could confuse the operational channel later.

The privacy boundary for WhatsApp Cloud API setup is specific: FormBeacon encrypts channel credentials and templates with versioned AES-256-GCM keys. It does not persist form answers, rendered notification bodies, raw provider payloads, OAuth or identity tokens, or complete billing webhook payloads. Retry storage in Google document properties is limited to form ID, response ID, idempotency key, and attempt count; the response is re-read from Google for a retry.

Those controls do not automatically make every form suitable for WhatsApp Cloud API setup. You remain responsible for lawful collection, notices, consent where required, access control, retention at Google and the provider, and any industry-specific rules. This article explains product behavior and operational precautions; it is not legal advice.

Meta asset, token, number, and template boundaries

  • WhatsApp approved templates are Business only.
  • FormBeacon does not create Meta business assets, approve templates, or absorb Meta provider fees.
  • Response values cannot choose recipient, token, phone-number ID, WABA, template identity, or language.
  • Screenshots must hide tokens, phone numbers, IDs, account email, QR codes, and unrelated business assets before capture.

If WhatsApp Cloud API setup requires a behavior listed here as a limit, do not hide the gap with copy or assume a future feature exists. Change the workflow, separate the forms, or choose a system that owns the missing behavior. Clear boundaries make setup and incident response easier.

Keep the first provider request deliberately simple

For WhatsApp Cloud API setup, FormBeacon sends an approved WhatsApp template. It synchronizes safe template metadata, requires an approved status and exact language, and maps stable form-field IDs only to declared header, body, and dynamic URL-button slots.

The first message for WhatsApp Cloud API setup should identify the form, state when the response was submitted, include only the information the first reader needs, and supply a stable response reference when useful. Put the action before decorative context. On a phone, the first few lines should explain why the alert matters without requiring the reader to expand a card or decode internal abbreviations.

FormatBest useMain risk
BasicFirst setup, arbitrary respondent answers, incident fallbackLong forms can still create noisy messages
RichSupported emphasis, lists, quotes, code, and links on Standard or BusinessEach provider supports a different safe subset
AdvancedSchema-validated Slack Block Kit, Discord embeds, or Telegram optionsOnly supported fields and variable positions are accepted

Advanced mode in WhatsApp Cloud API setup is provider-specific and schema validated. Variable substitution is context-aware and JSON safe, and respondent values remain text: they cannot become keys, object structure, credentials, destinations, template identity, or routing. Basic mode remains the most resilient choice when a workflow does not need provider-specific structure.

Configuration acceptance checklist

When completing WhatsApp Cloud API setup, slow down at ownership and permissions. Open the form while signed into the account that should operate the integration. If several Google accounts appear in the browser, use a separate browser profile or private window so the account granting authorization is unambiguous. The account must be able to edit the form; a public responder link is not enough.

  1. 1Confirm the form title and open its editor, not its public response page.
  2. 2In the Google Forms editor, click the Extensions icon in the upper-left area and launch FormBeacon.
  3. 3Read Google's authorization screen and complete it only for the intended owner account.
  4. 4Open Manage FormBeacon from the add-on menu; the product uses a modal dialog rather than a permanent sidebar.
  5. 5Create or collect a Meta access token, WhatsApp phone-number ID, approved template, language, and destination number using the provider's official administration interface.
  6. 6Paste the secret directly into FormBeacon. Do not first place it in a note, chat message, spreadsheet cell, or shell history.
  7. 7Choose Basic mode, use a short template, save, and send the built-in test.
  8. 8Submit the copied form from its responder view and compare that delivery with the saved test.
  9. 9Only after Basic mode works should you add more destinations, Rich mode, or a supported Advanced mode.
  10. 10Write down the owner and recovery procedure without writing down the secret value.

Ownership is critical to WhatsApp Cloud API setup: Google installable triggers run as the account that created them, and their authorization is not automatically transferred merely because another person can edit the form. Google's current behavior is documented in Installable Triggers. If the owner changes, plan an explicit handover and test from a new response.

Finish WhatsApp Cloud API setup with a one-page runbook that a colleague can follow without access to your browser history. Record the form name, intended owner, destination name, provider administrator, approved message purpose, date of the last harmless end-to-end test, and where the fallback response record lives. Record how to rotate the credential, but never record the credential value. A production-ready setup remains understandable and recoverable when the original installer is unavailable.

If WhatsApp Cloud API setup uses Business workspace sharing, membership is not inferred from an email suffix. A member must be explicitly invited, the Google identity must include a verified hosted-domain claim, and that domain must exactly match the workspace. Shared connectors then let authorized workspace members reuse owner-managed destination credentials without exposing the secret value.

Separate authentication, permission, and payload errors

When WhatsApp Cloud API setup fails, keep the first failing layer visible. A Google authorization or trigger failure occurs before a provider sees the message. A FormBeacon entitlement, quota, identity, or configuration error occurs before provider acceptance. A provider rejection means the request reached the provider but did not satisfy its credential, permission, payload, destination, or policy requirements. These are different problems and should not be collapsed into 'not configured.'

Failure familyWhat it usually meansSafe response
Authorization or triggerThe operating Google identity cannot run the installed event pathReopen as the intended owner, review authorization, and recreate only the intended trigger
Entitlement or limitThe selected form, destination count, format, or successful-delivery quota is outside the current planCompare the exact configuration with the pricing page; do not repeatedly recreate credentials
AuthenticationThe provider secret is invalid, revoked, expired, or belongs to another assetReplace it from the provider interface and keep the old value out of logs
Permission or destinationThe credential cannot post to the selected room, chat, number, or templateVerify provider-side membership and identifiers with a harmless test
Payload or policyThe provider rejected formatting, length, variables, template status, or another request ruleReturn to a minimal Basic document or approved template, then add complexity one change at a time
Transient provider or networkA dependency was temporarily unavailable or rate constrainedAllow bounded idempotent retry; do not create duplicate destinations or submit real responses repeatedly

When escalating a problem with WhatsApp Cloud API setup, provide the form's non-sensitive name, provider, approximate time with timezone, whether the saved test worked, whether a real submission worked, and the stable visible error code. Redact answers, webhook URLs, tokens, Meta identifiers that are treated as private in your organization, screenshots of personal data, and complete request or webhook bodies.

Account for destination and plan limits

Before launching WhatsApp Cloud API setup, match it to the pricing contract. Free supports one form, one active Basic destination on Slack, Discord, or Telegram, and 100 successful outbound destination deliveries per UTC calendar month. Standard supports up to 10 forms and Basic, Rich, and supported Advanced modes on Slack, Discord, and Telegram. Business adds WhatsApp approved templates, Webhook JSON, a shared 100-form workspace capacity, shared connectors, and unlimited explicitly invited workspace members.

For quota accounting in WhatsApp Cloud API setup, one notification is one successful delivery to one outbound destination. If one response is sent to three active destinations and all three succeed, that is three successful deliveries. A failed delivery does not consume the Free quota, and an idempotent retry of the same delivery must not count twice. The Free counter resets lazily when the UTC month key changes; there is no reset cron to wait for.

Multiple destinations attached to WhatsApp Cloud API setup use fan-out, not conditional routing. Every active destination on the form receives every eligible response. FormBeacon does not inspect an answer and select a destination, severity color, owner, or template branch. To keep different audiences separate, use separate forms or a workflow system that explicitly implements rules, and test that system with representative data.

Verify current FormBeacon amounts and included features for WhatsApp Cloud API setup on the pricing page. Product prices and provider charges are different: Meta or another provider may apply its own usage charges, taxes, or policies, and those charges are not replaced by a FormBeacon subscription.

Document Meta ownership and token replacement

Treat WhatsApp Cloud API setup like a small operational system. Name a form owner and a destination owner, document the purpose without recording secrets, and schedule a periodic harmless submission. Retest after changing form ownership, Google authorization, questions, destination membership, channel structure, webhook or bot settings, Meta templates, or the FormBeacon plan.

  • Keep a copy of the intended message structure without any credential or real response data.
  • Review whether every destination member still needs access to the notification content.
  • Remove unused destinations before creating new ones so fan-out remains understandable.
  • Use provider audit or administration features to investigate credential changes where available.
  • When an owner leaves, deliberately transfer the Google Form and recreate or verify the user-owned trigger under the intended owner.
  • During an incident, preserve timestamps and stable error codes, but redact identities, credentials, answers, and complete payloads.

The fallback for WhatsApp Cloud API setup should remain visible: authorized staff can open Google Forms and inspect responses when chat delivery is delayed. Do not delete or mutate a form response simply because a notification failed. Repair the delivery path, make a harmless test, and use the response reference to reconcile operational action without copying the original answers into troubleshooting logs.

Frequently asked questions

Does FormBeacon store submitted answers?
No. FormBeacon does not persist answers, rendered messages, or raw provider payloads. Google Forms remains the response record; providers retain messages they accept under their own controls.
How are Google Form fields mapped?
The variable picker stores the stable Google item ID. Renaming a question or giving two items the same title does not redirect a saved variable to another field.
Can an answer choose a destination or credential?
No. Respondent values remain text and cannot control credentials, endpoints, recipients, object structure, template identity, or routing.
Who pays Meta WhatsApp fees?
The customer uses their own Meta account and credentials. Applicable Meta charges remain in that Meta account; FormBeacon adds no WhatsApp usage fee.

Set this up on your own form

Follow the installation guide to install the add-on, connect a destination and send a test alert. FormBeacon does not persist form answers or rendered notification bodies.