Send landing-page leads into a Make scenario

Design the scenario around the final record

A Make scenario can receive a Pageree form submission, transform the values, look up existing records, and write the result to a destination. Define that final result first. “Put each quote request in Airtable” needs different duplicate handling from “keep one CRM contact per email.”

This is a documented implementation recipe, not a native Pageree Make app or a report of live account testing. You will need to authorize the destination, configure the scenario, and verify a controlled public-page submission in your own accounts.

Create a custom webhook with an explicit structure

Add Webhooks → Custom webhook to a new scenario and generate its unique URL. Make’s webhook app documentation describes JSON input, optional API-key authentication, and data-structure validation. If you enable that authentication, put the configured key in the x-make-apikey header through secure Pageree settings. Do not paste the key into the page or an AI conversation.

Send Pageree’s default payload to the generated URL with POST. Define a structure that matches your real form: top-level form, page, submittedAt, a data object, and relevant meta values. A representative sample helps expose mapping fields, but detecting fields from a sample is not the same as defining validation rules for every later request.

Incoming field	Example scenario use
data.email	Search for a contact or fill an email field
data.name	Contact/display name
data.project_type	Match an approved category or preserve as text
data.message	Long-text enquiry description
page	Source page context
submittedAt	Delivery time, not a stable replay identifier

Connect the destination through Make’s authorized connection. For an Airtable example, use a create-record module for the approved table and map each value to the verified field type. For a CRM, a lookup and conditional create step may precede the opportunity record.

Separate acceptance from completion

Make’s webhook processing guide explains that a successful default response can mean the request entered its queue. The following module may still fail. Plan to inspect scenario runs and the destination, and configure an error path that tells the responsible person which operation needs attention.

Pageree’s HTTP delivery currently times out after ten seconds. Do not hold its request open for a long scenario and assume the sender will wait indefinitely. A durable accepted queue plus monitored downstream processing is a different contract from synchronous end-to-end completion. A late scenario write can occur after a timeout, so check for partial success before replaying a submission.

Instant webhook scenarios can process requests in parallel. If your lookup/create logic depends on order, consider Make’s setting to process data in order, while recognizing that this does not create a universal exactly-once guarantee. Persist record IDs and a workflow key where duplicates would cause problems.

Copy this scenario prompt

Plan a Make scenario for Pageree page [page ID].
Destination and result: [exact table/object and desired record].
Receive the default JSON through a Custom webhook with a verified
data structure. If API-key authentication is enabled, use the
x-make-apikey header in secure settings; never expose its value.

Read the published form schema. Map actual fields and convert
types explicitly. Explain lookup/create behavior, repeat enquiries,
parallel processing, partial failures, and recovery. Remember that
Pageree waits ten seconds for HTTP delivery, and webhook acceptance
is not proof of a completed destination operation.

Show the setup for review. Provide controlled tests from the public
form through to final records; do not claim those tests were run.

Test successful and failed paths

Prepare a distinct test enquiry with an address you control. Put the scenario in the appropriate receiving state and submit through the published page. Private draft submissions go to email, so they cannot establish that Make received a webhook.

Inspect the received bundle, each module’s output, and the final destination record. Test an optional blank field and a repeated email with a different enquiry. In a separate test scenario, simulate a destination failure without disrupting production delivery, and verify who receives the alert and how the run can be resumed.

Pageree retains accepted submissions for 30 days and can fall back to owner email if HTTP delivery fails. Once email fallback succeeds, it does not automatically retry the Make request. An HTTP success followed by an Airtable failure needs recovery in the scenario, not a claim that Pageree’s fallback wrote the missing record.

Use the Airtable guide or Pipedrive guide for destination-specific mappings. If the public form never produces an accepted submission, start with form troubleshooting before changing scenario modules.