Overview

Reference only. Fired once per submitted contact/lead form — not something you call. Unrelated to the store.

• Contact Form Url — the GET-mode version, submitted fields baked into the URL.
• Contact Form Payload — the POST-mode version, submitted fields as a JSON body.

Both document the same webhook — GET vs POST is a mode you pick in the admin, not two separate webhooks.

Where the URL comes from. The site-level webhook (System > Site Settings > “Codes and Scripts” > “Webhook for Forms”) covers every form on the site. A form can also carry its own webhook URL, set in the form editor under the form’s settings (“Webhook לטופס זה”) — that one is always POST-JSON, receives the same Contact Form Payload, and overrides the site-level URL for that form only.

Field aliases. Each form field can be given a short English alias in the form editor (name, email, phone, message, …). In the POST payload, aliased fields become stable top-level JSON keys; fields without an alias arrive as {Name, Value} pairs keyed by their visible (typically Hebrew) label. In GET mode, {alias} works as a placeholder alongside {field label}. formID, pageTitle, fields and utm are reserved and can’t be used as aliases.

Migration note. The POST payload used to be a flat JSON object keyed directly by the Hebrew field labels. If your integration was built against that format, remap it once against the new shape documented in Contact Form Payload — or simply set aliases on your form’s fields and read the stable English keys.