Gravity Forms Webhooks Without the Elite Add-On — Built by AI in the Plugin

Describe It Once — The Agent Builds It

Open Webhook Actions in the WordPress admin and type:

prompt — paste into Build with AI

When a Gravity Forms form is submitted, send the entry as JSON to my webhook: https://your-n8n-url/webhook/test

Click to expand

The agent first gathers context — you'll see read-only ability chips like list_triggers and get_trigger_schema as it scans the action hooks available on your site and finds gform_after_submission, which fires once per successful entry after validation passes and the entry is stored.

It then proposes an ordered plan: create the webhook, point it at your endpoint, and — once a captured payload exists — map the numeric Gravity Forms field IDs to readable keys. With "Review plan before running" enabled you can edit any step before it executes.

Click to expand

When the run finishes you get "Build complete." with a one-click enable toggle. New webhooks are always created disabled — nothing fires until you confirm. Endpoint auth goes through the encrypted Credentials Vault (auth_credential_id), never plaintext headers, and the agent will never ask you to paste a secret into the chat.

Click to expand

Prefer to Set It Up by Hand?

The same result takes five steps in the admin UI — no AI provider needed:

1. 1
   Install the plugin

   Search for FlowSystems in Plugins → Add Plugin — it narrows the WordPress.org search to exactly one result.

2. 2
   Create a new webhook

   Go to Webhooks → Add Webhook, name it (e.g., "Gravity Forms → n8n").

3. 3
   Select the trigger

   Set the WordPress action hook to gform_after_submission — it fires once per successful Gravity Forms entry.

   action hook — paste into the trigger field

   gform_after_submission

   ⎘
4. 4
   Set the endpoint URL

   For n8n: add a Webhook node, set HTTP Method to POST, and copy its Production URL into the plugin's webhook URL field. The full n8n path — bearer auth, payload mapping, end-to-end test — is in Send Gravity Forms Submissions to n8n via Webhook.

5. 5
   Save and test

   Submit your Gravity Forms form. Check the Event Log in the plugin admin to see the delivery status and the raw payload that was sent.

   Click to expand

Writing the integration yourself with gform_after_submission and wp_remote_post()? The hook parameters, rgar() field access, and why bare HTTP calls silently drop entries in production are covered in the gform_after_submission hook reference.

Example Payload

Here's what a typical Gravity Forms submission looks like when it arrives at your endpoint. The args property is an array — args[0] is the entry, args[1] is the full form definition (fields, confirmations, notifications) and is omitted here for brevity.

Field values are stored under their numeric field ID as string keys: "1" is Full Name, "2" is Email, and so on.

POST body — application/json (args[1] form definition omitted)

{
  "event": {
    "id": "efab972c-09bc-460b-9ec3-ad63484b3b14",
    "timestamp": "2026-04-01T15:30:47Z",
    "version": "1.0"
  },
  "hook": "gform_after_submission",
  "args": [
    {
      "id": "3",
      "status": "active",
      "form_id": "1",
      "ip": "172.22.0.1",
      "source_url": "https://your-wordpress-site.com/gravity-forms-example/",
      "currency": "USD",
      "date_created": "2026-04-01 15:30:47",
      "created_by": "1",
      "1": "Mateusz",
      "2": "[email protected]",
      "3": "(150) 010-0900",
      "4": "general",
      "5": "Hey, this is example test form message!"
    }
  ],
  "timestamp": 1775057447,
  "site": {
    "url": "https://your-wordpress-site.com"
  }
}

Numeric keys are unwieldy in workflows — which is why the field mapping matters. Build with AI applies it for you via the captured payload (dot-notation paths like args.0.1 → name), so every future delivery arrives with name, email, phone instead of "1", "2", "3". You can do the same in the admin UI without code:

Mapping is also scriptable over HTTP — see the REST API reference for the PUT /schemas route.

What You Get Beyond the Setup

Every delivery is dispatched from a background queue, so form submissions are never blocked by a slow or unavailable endpoint. Failures retry automatically with exponential backoff — 1 min, 2 min, 4 min, 8 min, 5 attempts — and every attempt is logged with status code and response body. Anything that exhausts its retries stays in the event log, replayable from the admin UI or via the REST API (POST /wp-json/fswa/v1/logs/{id}/retry) — without asking the user to resubmit.