Try it out

🔗 1. Webhook Entry & Initial Decryption Block

Nodes involved:

• Webhook1
• move to base64
• [partially visible node for decryption using RSA + AES]

Description:

The workflow begins with the Webhook1 node, which listens for incoming HTTP POST requests. These requests typically contain encrypted data that needs to be decoded to proceed with processing.

Once received, the move to base64 node reformats the incoming encrypted components (encrypted_flow_data, encrypted_aes_key, and initial_vector) into binary buffers. These are required inputs for decryption.

Then, the custom JavaScript code (cut off in your snippet) uses a private RSA key to decrypt the AES key, which in turn is used to decrypt the actual data payload (likely using AES-GCM). This is a secure hybrid encryption method—RSA for key exchange, AES for data encryption.

---

🧠 2. Payload Parsing & Preprocessing Block

Node involved:

• Json Parser

Description:

Here, we take the decrypted JSON payload from Whatsapp Flows and parse key elements from it. This helps standardize and clean the input before deciding what kind of logic or response should follow based on user interaction.

---

🔀 3. Flow Decision Block

Node involved:

• Switch

Description:

This decision-making node routes the workflow depending on the screen context extracted earlier.

E.g., If the screen where the user is exchanging information is appointment date:

• "APPOINTMENT" → follow the logic that handles scheduling data.

This allows dynamic routing within the workflow, making it adaptable to different user journey steps or screens.

---

📆 4. Appointment Data Handling Block

Nodes involved:

• Data Extraction Code
• Respond to Webhook1

Description:

When the screen is "APPOINTMENT", the Data Extraction Code node processes appointment data—typically grouping appointment slots by date. This is useful for summarizing available times, perhaps to show a user a calendar view of options.

The results are then sent back as a plain text response using Respond to Webhook1, which finalizes the API call and ensures a secure end-to-end interaction using Whatsapp Flows.

🧩 Summary

This n8n workflow handles encrypted user interactions and adapts dynamically based on the screen or step the user is currently in. Here's the general pattern:

1. Webhook receives encrypted data
2. Data is decrypted using hybrid RSA-AES encryption
3. Parsed to extract the current step (screen)
4. Conditional logic decides which path to follow
5. Extracts relevant information (e.g., appointments)
6. Returns response back to the user interface or chatbot

🔗 1. Webhook Entry & Initial Decryption Block

Purpose and structure

This folder contains the 🔗 1. Webhook Entry & Initial Decryption Block workflow. Its executable nodes use code, respondToWebhook, switch, webhook. The table and connection map below are derived from the JSON, not an inferred guarantee of behavior.

Setup

Import inactive. Configure your own credentials and replace REPLACE_WITH_* values. Review external destinations and Code nodes before running.

Entry points

Webhook1

Verification

Sanitized source candidate; not runtime-tested. This overview is generated from node metadata. Read the folder README for the connection map, credential types, and license.

Attribution

https://github.com/Zie619/n8n-workflows/blob/94007c1445d9258a7da116646b79473e7c7c3282/workflows/Code/0924_Code_Respondtowebhook_Process_Webhook.json MIT; preserve source notices.