Building a Native WhatsApp Forms Engine on PrismWA

Built a screen-by-screen editor with a drag-and-drop component palette covering 14 field types - headings, text inputs, dropdowns, radio and checkbox groups, date pickers, opt-ins, photo/document pickers, plus If/Switch branching and a footer action - alongside a phone-frame preview that renders the screen exactly as it will appear in WhatsApp as it's being built.

Every WhatsApp Flow with dynamic screens needs a public/private RSA key pair: PrismWA generates a 2048-bit RSA key pair per flow, uploads the public key to Meta, and keeps the private key server-side. When a user's phone requests a screen, Meta encrypts the request with a fresh AES-128-GCM key wrapped in our RSA public key; PrismWA unwraps it, decrypts the payload, computes the response, and re-encrypts it with the same AES key under a flipped initialization vector, exactly as Meta's protocol requires.

A screen's live data can come from three sources, configured per-screen with no code: a static list, an external API call (with input field mapping and a JMESPath expression to reshape the response), or a sandboxed custom JavaScript function with access to the user's phone number, form data, and encrypted secrets. Functions run through a safe fetch with SSRF protection (blocking private IPs and cloud metadata endpoints) and a hard timeout.

Publishing hashes the transformed flow JSON and skips the Meta round-trip entirely if nothing actually changed (e.g., only a data-source URL was edited) - so config tweaks don't re-trigger Meta's validation and asset upload pipeline unless the form itself changed. Completed forms arrive as a WhatsApp webhook (nfm_reply), get de-duplicated by flow token, stored as structured submissions (with any uploaded photos/documents downloaded automatically), and optionally forwarded to an external API with configurable field-name mapping and per-submission resend.

Problem: Meta's Data Exchange protocol fails silently on the device ("Something went wrong") if the AES-GCM auth tag handling or IV-flip is even slightly off, with almost no error detail returned.

Problem: Meta's publish step transforms our stored flow JSON for its own copy without writing the transformed routing_model back to our database, so the stored flow often has an empty routing model - which broke "next screen" navigation during data exchange.

Problem: Letting admins write custom JavaScript to power a screen means running arbitrary code inside the same process as the API - a real sandbox escape risk if function authorship were ever opened beyond trusted roles.