How to connect WordPress forms to a CRM

Write down the fields your CRM needs before changing the form. Usually this includes email, first name, last name, phone, company, message, consent status and the page or campaign that produced the lead.

Check the CRM property names and allowed values. A form field labelled Industry may need to send the CRM's internal value rather than the visible label. Decide whether an existing contact should be updated when the email address already exists.

Add every required field to the WordPress form, then create matching custom properties in the CRM where necessary. Keep email as a required field if the CRM uses it to identify contacts.

Do not send passwords, payment details or other unnecessary personal data. Add a clear consent checkbox if you will use the lead for marketing, and make sure the CRM has somewhere to store that consent.

Use the CRM's official WordPress integration or an automation service when one supports your form plugin. If your form plugin can send webhooks, point it at the CRM endpoint or an automation workflow. A webhook is an HTTP request sent when the form is submitted; Gravity Forms documents POST requests, JSON or form data, custom headers, selected fields and conditional feed logic for this purpose.

If neither option exists, you need custom code or a connector plugin. WordPress itself does not know how to translate every form plugin's entry into every CRM's API.

For Gravity Forms, install and enable its Webhooks Add-On, open the form editor, then go to Form Settings → Webhooks and create a feed. Enter the CRM or automation webhook URL, normally use POST, choose JSON when the receiving API expects JSON, add authentication headers if required, and map only the fields you need. Add feed conditions when only some submissions should become CRM leads.

For a custom integration, use the form plugin's documented submission hook and send the request server-side with WordPress's HTTP API. Gravity Forms documents gform_after_submission for sending entry data to a third party and wp_remote_post() is WordPress's built-in POST request function. Store tokens outside the form's front-end JavaScript.

The drawback is maintenance: a renamed form field, changed CRM property, expired token or API validation rule can stop lead capture without making the form itself look broken.

Map each WordPress field to the CRM's internal property name, not just the label shown in the form builder. Send a single, normalised value for dropdowns and checkboxes, and convert phone numbers and dates to the format the CRM accepts.

Use HTTPS and a server-side secret or signed webhook where supported. If you send data to HubSpot's Forms API, the submission must use the portal ID and form ID, and fields must satisfy the form definition and validation rules. HubSpot provides an unauthenticated submission endpoint for ordinary form data and a secure variation for sensitive data.

Submit the form with a new test email, then check the CRM record, field values, list membership, owner assignment and any workflow activity. Repeat with an existing email to confirm whether the CRM updates the contact or creates a duplicate.

Test blank optional fields, special characters, phone numbers, consent unchecked, conditional fields and spam-protection failures. Check the WordPress form entry and the CRM's integration or API log. The common Friday failure is a successful-looking form submission followed by a rejected API request because a property name, required field or option value no longer matches.

If the form is built with Gravity Forms and the destination is HubSpot, the Gravity Forms HubSpot Addon is the quicker route. It is designed to map submissions to HubSpot properties, apply conditional logic and send leads without maintaining the API request yourself.

Install the addon through WordPress, activate it, connect the HubSpot account in the Gravity Forms settings, select the form, create the HubSpot feed and map the fields. Still run the same duplicate, consent and failure tests before sending live traffic.