DEV Community: Rahul Sharma

CF7 to Monday.com Item Not Appearing in Board: A Complete Troubleshooting Guide

Rahul Sharma — Thu, 12 Nov 2026 06:20:41 +0000

You have connected Contact Form 7 to Monday.com through a connector plugin. The API logs show a successful 200 OK response. The item ID is returned. Everything looks correct.

But when you open the board in Monday.com, the item is not there.

This is one of the most confusing integration failures because the API tells you it succeeded. The request was valid. The item was created. But it is invisible to you.

This guide explains exactly why this happens and how to fix it.

Why Monday.com Says "Success" When the Item Is Invisible

Monday.com's API creates items at the account level, not at the board level. The create_item mutation accepts a board_id and returns the created item's ID and URL. But the item's visibility depends on two factors that the API response does not validate:

Permission scope of the API token. If the API token belongs to a user who does not have access to the board, or if the token's permissions are limited, the item is created but is not visible to anyone viewing the board through a different user account.

Column ID and value format. If the columnValues payload contains incorrect column IDs or value formats, Monday may accept the request but silently ignore the column values, creating an item with empty fields that does not appear in filtered views.

The first is the most common cause. A Monday.com community response confirmed this directly: "The solution was a permission issue. The API key used wasn't from the same user which I was using to view the board. The solution is to add permissions or create an API Key from the user I want to see the items."

Failure #1: The API Token Belongs to a Different User

What you see: The API returns a successful response with an item ID. The item URL works when accessed directly. But the board view does not show the item.

Why it happens: Monday.com's API token is tied to a specific user account. If you generated the token from User A, but you are viewing the board as User B, and User B does not have permission to see items created by User A, the item is invisible in your view. This is not a bug. It is how Monday's permission model works.

The fix:

Option A: Generate the API token from the user who will view the board. If your team views the board as admin@company.com, generate the API token while logged in as admin@company.com. This ensures the item is created under the same account context.

Option B: Grant the token's user access to the board. If you must use a service account token, add that service account as a board member with edit permissions. Navigate to the board, click "Invite," and add the user associated with the API token.

How to verify: After generating a new token from the correct user, submit a test form. Check the board while logged in as that same user. The item should appear.

If no request appears in the plugin's logs at all, the problem is earlier in the pipeline. For a deeper breakdown of that scenario, see this guide on Contact Form 7 data not reaching the API.

Failure #2: The Column IDs in the Payload Are Wrong

What you see: The item appears in the board, but all column values are empty. Or the item is created in the wrong group and does not appear in the filtered view you are checking.

Why it happens: Monday's create_item mutation requires column IDs, not column display names. If your payload uses "status": {"label": "Done"} but the actual column ID is "status_mm37gbqg", Monday ignores the value.

The same applies to group IDs. If you do not specify a group_id, the item goes to the board's top group. If you are checking a different group, the item appears to be missing.

The fix:

Step 1: Retrieve the correct column IDs. Use Monday's get_board_info tool or query the board via GraphQL to list all columns and their IDs. The column ID is not the same as the column title.

Step 2: Update your JSON payload. For a status column, the format is:

{
  "status_mm37gbqg": {
    "label": "Working on it"
  }
}

For a text column, the format is a plain string:

{
  "text_col": "Hello"
}

For a date column:

{
  "date_col": {
    "date": "2024-05-10"
  }
}

Step 3: Specify the group ID if needed. If you want the item in a specific group, add groupId to your payload. Otherwise, it goes to the top group.

For a deeper dive into JSON structure mapping and column value formatting, read this guide on Contact Form 7 JSON mapping.

Failure #3: The Payload Structure Is Wrong for Monday's GraphQL API

What you see: Monday returns a 400 Bad Request error, or the item is created with no name and no column values.

Why it happens: Monday.com uses GraphQL, not REST. The connector plugin may be configured to send a REST-style JSON body, which Monday's API does not accept. The create_item mutation expects a specific GraphQL structure.

The fix:

Monday's GraphQL create_item mutation requires three parameters at minimum:

board_id: The numeric ID of the board
item_name: The name of the item (a plain string)
column_values: A JSON string containing column ID to value mappings

Your payload sent through the plugin should be structured as a GraphQL query. If your connector plugin supports raw JSON payloads, the body must include the query and variables fields:

{
  "query": "mutation ($boardId: ID!, $itemName: String!, $columnValues: JSON) { create_item(board_id: $boardId, item_name: $itemName, column_values: $columnValues) { id } }",
  "variables": {
    "boardId": 18412502536,
    "itemName": "[your-name] - Website Inquiry",
    "columnValues": "{\"status_mm37gbqg\": {\"label\": \"New\"}}"
  }
}

Critical detail: The columnValues parameter is a JSON string nested inside the GraphQL variables. This "JSON-in-JSON" pattern is specific to Monday's API and is the source of many payload errors.

If your connector plugin does not support GraphQL queries, you may need to use a plugin that does, or configure a middleware service to translate the request.

Failure #4: The Board ID Is Wrong or the Token Lacks Board Access

What you see: Monday returns a 404 Not Found error, or a 403 Forbidden error. No item is created.

Why it happens: The board_id in your payload must be the numeric ID of the target board. If you use the board's URL slug instead of its ID, the request fails. Additionally, the API token must have access to that specific board.

The fix:

Step 1: Get the correct board ID. Open the board in Monday.com. The URL contains the board ID: https://yourcompany.monday.com/boards/18412502536. The numeric portion is the board ID.

Step 2: Verify token access. In Monday.com, navigate to the board and check the board's members. The user associated with the API token must be listed as a member with at least edit permissions.

Step 3: Test with a minimal payload. Hardcode the board_id and item_name values. Submit a test form. If the item appears, the issue is column values or permissions. If it still fails, the token or board ID is wrong.

For a comprehensive breakdown of API authentication errors and how they appear in logs, see this guide on Contact Form 7 API authentication errors.

The Debugging Checklist

Step	Action	What It Reveals
1	Check the plugin's API Logs	Was a request sent? What response code and body?
2	Verify the API token's user	Is it the same user viewing the board?
3	Check board membership	Is the token's user a member of the board?
4	Verify column IDs	Are they the IDs from `get_board_info`, not display names?
5	Check the payload structure	Is it a GraphQL query, not a REST body?
6	Test with minimal payload	Hardcode `board_id` and `item_name` only

Beyond the Board: One Form, Multiple Destinations

Once your Monday.com integration works, you might want to send the same submission to other tools: a CRM, an email marketing platform, or a help desk system.

A good connector plugin supports multiple API integrations from a single form submission. You can create a Monday item, add a HubSpot contact, and send an SMS via Twilio, all from one CF7 submission. For a cost comparison, see this article on Zapier vs a dedicated API plugin.

Key Takeaways

The API can return success while the item is invisible. Monday's create_item response does not validate visibility. The item is created at the account level, and its visibility depends on the API token's user permissions.

Generate the API token from the user who views the board. If your team views the board as admin@company.com, create the token while logged in as that user.

Column IDs must be exact. Use get_board_info to retrieve the correct IDs. Display names do not work.

Monday uses GraphQL, not REST. The payload must be a GraphQL query with columnValues as a JSON string nested inside the variables.

Start with a minimal payload. Hardcode board_id and item_name. Once the item appears, add column values one at a time.

With the correct API token, verified board permissions, and a properly structured GraphQL payload, your CF7 submissions will create visible items in your Monday.com board reliably.

CF7 to HubSpot Deal Not Created: Why It Happens and How to Fix It

Rahul Sharma — Fri, 06 Nov 2026 12:24:16 +0000

You have connected Contact Form 7 to HubSpot. Contacts appear in your CRM. Companies are created. But deals? They never show up.

This is one of the most common frustrations with CF7-to-HubSpot integrations. The contact gets created. The deal does not. And the reason is not a bug in your plugin or a missing field mapping. It is a fundamental architectural fact about how HubSpot works.

HubSpot's form submission APIs are contact-centric. They are designed to create or update contacts. They do not create deals. Even if you include deal fields in a form submission, HubSpot's API ignores them.

This guide explains exactly why deals fail to create and walks through the verified solutions.

Why HubSpot Does Not Create Deals from Form Submissions

HubSpot's native form handling and its Forms API are built around contacts. When a form is submitted, HubSpot creates or updates a contact record. It may also create a company if the contact's email domain matches an existing company or if specific settings are enabled. But deals are not part of the default form submission flow.

A HubSpot community moderator confirmed this directly: "Out of the box form submissions do not create deals." Even if you put deal fields on a form definition, the submissions endpoint is designed to create or update the contact record only, then expose those values so you can act on them with workflows or other APIs afterward.

This means that regardless of which WordPress plugin you use "Contact Form to Any API," the official HubSpot plugin, or any other integration a standard form submission will not create a deal automatically.

If no contact appears in HubSpot at all, the problem may be earlier in the pipeline. For a deeper breakdown of that scenario, see this guide on Contact Form 7 data not reaching the API.

Failure #1: You Are Targeting the Contacts Endpoint, Not the Deals Endpoint

What you see: Contacts appear in HubSpot. Deals never appear. The plugin's API logs show a successful 200 or 201 response, because the contact creation succeeded.

Why it happens: The "Contact Form to Any API" plugin requires you to specify the API endpoint manually. If you are using the HubSpot Contacts endpoint (/crm/v3/objects/contacts), the plugin creates a contact and nothing else. There is no deal creation because the endpoint does not handle deals.

The fix:

You have two options. The first is to target the Deals endpoint directly. HubSpot's Deals API accepts a POST request to /crm/v3/objects/deals with a properties object.

Your payload would look like this:

{
  "properties": {
    "dealname": "[your-name] - Website Inquiry",
    "dealstage": "appointmentscheduled",
    "pipeline": "default"
  }
}

Critical detail: You must use the internal ID of a deal stage, not its display label. The internal ID for "Appointment Scheduled" might be appointmentscheduled, but you should verify this in your HubSpot deal pipeline settings.

The second option is to create the contact via the plugin and then use a HubSpot workflow to create the deal. This is the approach HubSpot recommends for most users.

Failure #2: The Deal Stage or Pipeline ID Is Wrong

What you see: HubSpot returns a 400 Bad Request error. The response mentions an invalid dealstage or pipeline.

Why it happens: HubSpot's Deals API requires internal IDs for dealstage and pipeline, not human-readable names. If you use dealstage: "New" but the internal ID is appointmentscheduled, the request fails.

The fix:

Step 1: In HubSpot, navigate to Settings → Objects → Deals → Pipelines.

Step 2: Click on your pipeline and locate the stage you want to use. The internal ID is displayed alongside the stage name.

Step 3: Update your JSON payload to use the internal ID:

{
  "properties": {
    "dealname": "[your-name] - Website Inquiry",
    "dealstage": "appointmentscheduled",
    "pipeline": "default"
  }
}

If you omit pipeline, HubSpot uses the default pipeline. If you omit dealstage, HubSpot may reject the request or use a default stage depending on your account configuration.

For a deeper dive into JSON structure mapping and payload construction, read this guide on Contact Form 7 JSON mapping.

Failure #3: The Workflow That Should Create Deals Is Not Firing

What you see: Contacts are created. The workflow you set up to create deals is either not enrolling contacts or not completing the deal creation action.

Why it happens: HubSpot workflows that create deals from form submissions require specific enrollment triggers and actions. If the enrollment criteria do not match the contact's properties, the workflow never runs. If the "Create record" action is missing or misconfigured, the deal is never created.

The fix:

Step 1: In HubSpot, navigate to Automation → Workflows.

Step 2: Check your deal-creation workflow. The enrollment trigger should be "Contact submitted form X" or "Contact property [specific field] is known."

Step 3: Verify the workflow contains a "Create record" action targeting Deals. The action should map contact properties to deal properties.

Step 4: Check the workflow's action log. If contacts are enrolling but the action fails, the log will show the error. If contacts are not enrolling, the enrollment criteria are too narrow.

A HubSpot community user described this exact problem: contacts were created from form submissions, but deals were not. The moderator confirmed that a workflow was required and asked the user to check the action log for enrollment or execution errors.

Failure #4: The Contact Has No Associated Company

What you see: Deals are created for some contacts (those with business email domains) but not others (those with Gmail, Yahoo, or other free email providers).

Why it happens: If your deal-creation workflow or HubSpot's automatic company association settings depend on the contact having a company, freemail contacts will not trigger deal creation. HubSpot's "Automatically create and associate companies with contacts" setting may block company creation for free email domains.

The fix:

Option A: Create a second workflow that enrolls contacts without an associated company and creates the company first. Then the deal-creation workflow can run.

Option B: Modify your deal-creation workflow to not require a company association. The deal can be created directly from the contact record without a company link.

Option C: Use the "Contact Form to Any API" plugin to call the Deals API directly, bypassing HubSpot's workflow logic entirely. This gives you full control over when a deal is created, regardless of the contact's email domain.

The Debugging Checklist

Step	Action	What It Reveals
1	Check the plugin's API Logs	Was a request sent? To which endpoint?
2	Verify the endpoint URL	Does it target `/deals` or `/contacts`?
3	Check the dealstage internal ID	Is it the ID, not the display name?
4	Check HubSpot workflow enrollment	Are contacts enrolling in the deal-creation workflow?
5	Check the workflow action log	Did the "Create record" action execute successfully?
6	Test with a business email	Does the deal create when the contact has a company domain?

For a comprehensive breakdown of API authentication and error handling across different integrations, see this guide on Contact Form 7 API authentication errors.

Beyond Deals: One Form, Multiple Destinations

Once your deal creation works, you might want to send the same submission to other HubSpot objects or external tools.

A good connector plugin supports multiple API integrations from a single form submission. You can create a HubSpot contact, a deal, and send an SMS via Twilio, all from one CF7 submission. For a cost comparison, see this article on Zapier vs a dedicated API plugin.

Key Takeaways

HubSpot form submissions do not create deals automatically. The Forms API and contact endpoints are contact-centric. Deals require either a direct API call to the Deals endpoint or a HubSpot workflow.

The Deals API requires internal IDs for dealstage and pipeline. Using display names instead of IDs causes 400 errors.

Workflows are the native HubSpot solution. Create a workflow that enrolls contacts from form submissions and uses the "Create record" action to create deals.

Freemail contacts may not trigger company-based workflows. If your workflow requires a company association, Gmail and Yahoo contacts may be skipped.

Direct API calls to the Deals endpoint give you full control. Use the plugin to POST to /crm/v3/objects/deals with the correct properties and IDs, bypassing HubSpot's workflow logic entirely.

With the right endpoint, correct internal IDs, and a properly configured workflow or direct API call, your CF7 submissions will create deals in HubSpot reliably.

CF7 Form Data Validation Before Sending to API: A Complete Implementation Guide

Rahul Sharma — Mon, 02 Nov 2026 05:09:00 +0000

You have a Contact Form 7 form connected to an external API. The form submits. The plugin fires the API request. And then the API rejects it—because the email domain is blocked, the phone number format is wrong for that specific service, or the field value violates a business rule the API enforces.

The user sees a generic success message. The API log shows a failure. And you have no way to tell the user what went wrong before the request was even sent.

This is the validation gap. CF7 validates what it knows: required fields, email format, file size. It does not know your API's rules. Bridging that gap requires custom validation that runs before the API request fires.

Why CF7's Built-in Validation Is Not Enough

Contact Form 7 provides default validation for common field types. A required field must be filled. An email field must contain a valid email address. A file upload must be within size limits .

But API integrations have rules CF7 does not enforce:

The email must belong to a business domain, not a free provider
The phone number must match the format expected by the CRM
The company name must exist in your ERP's customer database
The budget field must be within a range the sales team can handle

If the API rejects the submission, the user has already seen a success message (or the form hangs, depending on the plugin's response handling). The validation happened too late.

The Solution: Validate Before the API Call Fires

The key insight is that validation must happen at the CF7 submission stage, before the connector plugin sends data to the API. CF7 provides hooks that fire during its own validation process, giving you a chance to inject custom rules.

Approach 1: Custom Validation Filters (Legacy Method)

CF7 implements validation as a filter. The hook name follows the pattern wpcf7_validate_[field_type]. For a text field, it is wpcf7_validate_text. For a required text field, it is wpcf7_validate_text* .

A validation filter receives two parameters: the result object and the form tag. You check the field value and call $result->invalidate() if it fails your custom rule.

add_filter('wpcf7_validate_text*', 'validate_business_email_domain', 20, 2);

function validate_business_email_domain($result, $tag) {
    if ($tag->name !== 'your-email') {
        return $result;
    }

    $email = isset($_POST['your-email']) ? sanitize_email($_POST['your-email']) : '';
    $free_providers = ['gmail.com', 'yahoo.com', 'hotmail.com', 'outlook.com'];
    $domain = substr(strrchr($email, "@"), 1);

    if (in_array($domain, $free_providers)) {
        $result->invalidate($tag, 'Please use your business email address.');
    }

    return $result;
}

This validation runs during CF7's submission process. If it fails, CF7 marks the submission as invalid and does not proceed to the mail-sent stage—which means the connector plugin never fires the API request.

Approach 2: Schema-Woven Validation (Modern Method)

CF7 5.9 and later use Schema-Woven Validation (SWV), a rule-based system that provides both client-side and server-side validation from a single schema . The wpcf7_swv_create_schema action lets you add custom rules.

The advantage of SWV is that validation rules are defined once and enforced on both the frontend and the backend. Client-side validation gives instant feedback. Server-side validation prevents bypass via direct POST requests.

add_action('wpcf7_swv_create_schema', function($schema, $contact_form) {
    $rule = wpcf7_swv_create_rule('required', [
        'field' => 'company-name',
        'error' => 'Company name is required for business inquiries.',
    ]);
    $schema->add_rule($rule);
}, 10, 2);

For conditional rules, SWV supports all and any composite rules. An all rule requires every sub-rule to pass. An any rule requires at least one . This is useful for validation that depends on multiple field values.

Validating Against the API Before Submitting

Sometimes the validation rule itself lives in the API. For example, you want to check if a phone number is already registered in your CRM before creating a new lead.

You can make a lightweight validation request to the API inside your validation filter. The filter runs synchronously, so the user waits for the result.

add_filter('wpcf7_validate_tel*', 'check_phone_against_api', 20, 2);

function check_phone_against_api($result, $tag) {
    if ($tag->name !== 'your-phone') {
        return $result;
    }

    $phone = isset($_POST['your-phone']) ? sanitize_text_field($_POST['your-phone']) : '';

    $response = wp_remote_get('https://api.example.com/check-phone?number=' . urlencode($phone), [
        'timeout' => 5,
        'headers' => ['Authorization' => 'Bearer YOUR_TOKEN'],
    ]);

    if (!is_wp_error($response)) {
        $body = json_decode(wp_remote_retrieve_body($response), true);
        if (!empty($body['exists'])) {
            $result->invalidate($tag, 'This phone number is already registered.');
        }
    }

    return $result;
}

Caution: This adds latency to form submission. If the API is slow or unreachable, the form submission may time out. Use short timeouts and consider caching results where possible.

Conditional Validation: Only Validate When Necessary

Not every field needs validation on every submission. A budget field might only be required when the inquiry type is "Sales." A company name might only be required for business accounts.

CF7's SWV supports conditional logic through composite rules . But for simpler cases, the legacy filter approach with conditional checks works reliably.

add_filter('wpcf7_validate_text', 'conditionally_require_company', 10, 2);

function conditionally_require_company($result, $tag) {
    if ($tag->name !== 'company-name') {
        return $result;
    }

    $inquiry_type = isset($_POST['inquiry-type']) ? $_POST['inquiry-type'] : '';
    $company = isset($_POST['company-name']) ? trim($_POST['company-name']) : '';

    if ($inquiry_type === 'Business' && empty($company)) {
        $result->invalidate($tag, 'Company name is required for business inquiries.');
    }

    return $result;
}

This pattern is more flexible than SWV for complex conditions that reference multiple fields or external data.

The Critical Timing Question: Before or After the API Call?

The connector plugin fires the API request at a specific point in CF7's submission lifecycle. If your validation filter runs before that point, a failed validation prevents the API call. If it runs after, the API call fires regardless.

CF7's validation filters (wpcf7_validate_*) run during the validation phase, before the wpcf7_before_send_mail action. The "Contact Form to Any API" plugin hooks into the submission process at a later stage. This means custom validation filters will block the API call if they fail.

If you need to validate after the API responds (for example, checking if the API accepted the data), you are working with a different problem: surfacing the API's response to the user. That requires a separate solution involving the wpcf7mailsent event or custom response handling.

The Debugging Checklist for Validation Issues

Step	Action	What It Reveals
1	Submit a test form with invalid data	Does CF7 show your custom error message?
2	Check if the API request fired	If validation failed, the API call should not fire
3	Verify the hook name	`wpcf7_validate_text*` for required, `wpcf7_validate_text` for optional
4	Check field name match	The `$tag->name` must match your CF7 field name exactly
5	Test with valid data	Does the form submit and the API call fire?
6	Check for plugin conflicts	Other CF7 extensions may alter validation behavior

For a deeper breakdown of what happens when validation fails and no API request appears in the logs, see this guide on Contact Form 7 data not reaching the API.

Key Takeaways

CF7's built-in validation does not know your API's rules. Required, email format, and file size are not enough. Custom validation filters bridge the gap.

Validation must run before the API call fires. CF7's wpcf7_validate_* filters run during the validation phase, blocking submission if they fail.

SWV is the modern approach. Schema-Woven Validation provides client-side and server-side enforcement from a single rule definition.

Conditional validation prevents unnecessary friction. Only require fields when the form data actually demands them.

API-side validation adds latency. If you check against the API inside a validation filter, use short timeouts and cache results where possible.

With custom validation filters that run before the connector plugin fires, your form rejects invalid data at the source. The user gets a clear error message. The API never sees the bad request. And your CRM stays clean.

CF7 to Salesforce Custom Object Not Created: A Complete Troubleshooting Guide

Rahul Sharma — Fri, 30 Oct 2026 10:19:29 +0000

You have configured the "Contact Form to Any API" plugin to send Contact Form 7 submissions to a custom object in Salesforce. You have set up OAuth, entered your credentials, and mapped the fields. And yet, when a user submits the form, no record appears in your custom object.

This is a common and frustrating problem. Writing to custom objects is fundamentally different from writing to standard objects like Leads. The error messages are often vague, and the root cause is usually one of four specific configuration mistakes.

This guide walks through the exact reasons custom object creation fails and how to fix each one.

Why Custom Objects Are Different from Standard Objects

Salesforce standard objects like Lead or Contact have well-documented, predictable API names. Custom objects do not share this predictability.

Every custom object and every custom field in Salesforce has an API name that ends with __c (two underscores followed by the letter c). This suffix is not optional. If you omit it, Salesforce rejects the request with an INVALID_FIELD error, even though the field exists in the UI.

This is the single most common reason custom object creation fails.

Failure #1: The Endpoint URL Is Missing the `__c` Suffix

What you see: Salesforce returns a 404 Not Found error, or the request succeeds but creates a record in the wrong place.

Why it happens: The endpoint URL for a custom object must include the __c suffix. If your custom object is named Project_Request, the API endpoint must be:

/services/data/v63.0/sobjects/Project_Request__c/

If you omit the __c, Salesforce looks for a standard object named Project_Request, which does not exist.

The fix:

In the plugin's API Endpoint URL field, verify the URL ends with __c/. For example:

https://yourdomain.my.salesforce.com/services/data/v63.0/sobjects/Project_Request__c/

Replace yourdomain with your Salesforce instance URL and Project_Request with your actual custom object name.

How to verify: After submitting a test form, check the plugin's API Logs. A 404 error means the endpoint is wrong. A 201 Created response means the record was created successfully. For a deeper breakdown of what empty logs mean, see this guide on Contact Form 7 data not reaching the API.

Failure #2: The Field Names Are Missing the `__c` Suffix

What you see: Salesforce returns an INVALID_FIELD error with a message like: "No such column 'Project_Type' on sobject of type Project_Request__c".

Why it happens: Just like the object name, every custom field's API name ends with __c. If your custom field is labeled "Project Type" in the Salesforce UI, its API name might be Project_Type__c. In your JSON payload, you must use the API name, not the label.

The fix:

Step 1: In Salesforce, navigate to Setup → Object Manager → Your Custom Object → Fields & Relationships. For each field you want to map, copy the API Name exactly as shown, including __c.

Step 2: In the plugin's JSON payload, use the API name, not the label:

{
  "Name": "[your-name]",
  "Project_Type__c": "[project-type]",
  "Budget__c": "[budget-range]"
}

Step 3: Verify the field names match exactly. One missing underscore means a failed request.

For a deeper dive into JSON structure mapping and field naming conventions, read this guide on Contact Form 7 JSON mapping.

Failure #3: The User Lacks Permission to Create Records on the Custom Object

What you see: Salesforce returns a 403 Forbidden error, or an INSUFFICIENT_ACCESS error. The API call authenticated successfully but was rejected.

Why it happens: Creating a custom object does not automatically grant permission to write to it. As a Salesforce administrator, you can see the object in Setup. But API access requires explicit permission on the object and on every custom field you want to populate.

The fix:

Step 1: In Salesforce, navigate to Setup → Users → Profiles (or Permission Sets).

Step 2: Find the profile or permission set associated with the user whose credentials the plugin uses.

Step 3: Grant the following permissions:

Object Permissions: Create, Read, Edit on the custom object
Field-Level Security: Edit access on every custom field you are mapping

Step 4: Save the permissions. Wait a few minutes for Salesforce to propagate the changes.

How to verify: After updating permissions, submit a test form. A 201 response means the record was created.

Failure #4: The OAuth Token Does Not Have the Correct Scope

What you see: Salesforce returns a 401 Unauthorized error, or the token works for standard objects but fails for custom objects.

Why it happens: Salesforce OAuth tokens are scoped. The api scope grants access to standard objects, but custom objects may require additional permissions or a different scope configuration.

The "Contact Form to Any API" plugin's PRO version with the OAuth Add-on handles Salesforce's OAuth 2.0 flow, including automatic token refresh. If you are using the free version without the OAuth Add-on, token management may be incomplete.

The fix:

Step 1: Verify you are using the PRO version with the OAuth Add-on. The free version does not support automatic token renewal, which means expired tokens will cause failures.

Step 2: In the plugin's Auth Master settings, confirm the OAuth scopes include:

api (Access and manage your data)
refresh_token and offline_access (for automatic token refresh)

Step 3: Re-authorize the connection. In the plugin, click Authorize again to generate a fresh token with the correct scopes.

For a comprehensive breakdown of authentication errors across different APIs, see this guide on Contact Form 7 API authentication errors.

The Debugging Checklist

Step	Action	What It Reveals
1	Check plugin API Logs	Was a request sent? What response code?
2	Verify endpoint URL ends with `__c/`	Custom object endpoint format
3	Verify field API names end with `__c`	Field naming convention
4	Check user permissions on the object	Object-level create/edit access
5	Check field-level security	Edit access on each mapped field
6	Verify OAuth token scopes	`api`, `refresh_token`, `offline_access`

Beyond Custom Objects: One Form, Multiple Destinations

Once your custom object integration works, you might want to send the same submission to other Salesforce objects or external tools.

A good connector plugin supports multiple API integrations from a single form submission. You can create a custom object record, a standard Lead, and send an SMS via Twilio, all from one CF7 submission. For a cost comparison, see this article on Zapier vs a dedicated API plugin.

Key Takeaways

Every custom object and custom field API name ends with __c. Omitting this suffix is the most common cause of INVALID_FIELD and 404 errors.

Creating the object does not grant write permission. You must explicitly grant Create/Edit permissions on the object and Edit access on every custom field.

The endpoint URL must target the custom object by its API name. /sobjects/Your_Object__c/ is the correct format.

OAuth scopes must include api and refresh capabilities. Without proper scopes, the token may work for standard objects but fail for custom ones.

Use the PRO version with the OAuth Add-on for Salesforce. The free version does not handle automatic token refresh, which is essential for long-term reliability.

With the correct __c suffixes, proper permissions, and valid OAuth scopes, your CF7-to-Salesforce custom object integration will create records reliably.

CF7 API Response Not Showing to User: Why It Happens and How to Fix It

Rahul Sharma — Thu, 29 Oct 2026 09:35:18 +0000

You have configured the "Contact Form to Any API" plugin to send form submissions to an external service. The API returns a meaningful response a success confirmation, a validation error, a duplicate email warning, or a custom message. And yet, the user sees nothing. The form submits, the default CF7 success message appears, and the API's response is buried in the plugin's admin logs.

This is not a bug. It is a documented limitation of the plugin's architecture. But it creates a frustrating user experience, especially when the API rejects the submission for a reason the user needs to know about.

This guide explains why API responses are hidden from users and walks through the verified workarounds to surface them.

Why the Plugin Hides API Responses from Users

The "Contact Form to Any API" plugin hooks into Contact Form 7's submission process at the wpcf7_mail_sent action. This means the API request fires after CF7 has already decided the submission was successful and displayed its default success message.

From the plugin's perspective, the API call is a side effect of a successful form submission. The plugin logs the request and response for administrative review, but it does not inject that response into CF7's frontend message system. The plugin's official documentation describes the Logs feature as showing "your API response" for admin review, not for user display.

The developer confirmed this limitation directly: the plugin was "created after form successfully submitted" and "at the moment it is not possible to manage API side errors to display on cf7 forms".

If no request appears in the logs at all, the problem may be earlier in the pipeline. For a deeper breakdown of that scenario, see this guide on Contact Form 7 data not reaching the API.

The Consequence: Users See Success When the API Failed

Because the API call happens after CF7's success determination, a user can see "Thank you for your message" even when the API rejected the submission entirely.

This is a serious problem for workflows where the API response contains information the user needs:

A duplicate email warning that should prompt the user to log in instead
A validation error about a phone number format
A capacity limit message for an event registration
A custom confirmation number or reference ID

The user believes their submission succeeded. The API knows it failed. And the only record of the failure is in an admin log the user cannot see.

Workaround 1: Hook into `wpcf7_before_send_mail` and Inject a Custom Message

The most direct workaround, provided by the plugin's developer in a support thread, involves changing the hook timing and using CF7's wpcf7_display_message filter to replace the success message when the API returns an error.

Step 1: Change the Hook from `wpcf7_mail_sent` to `wpcf7_before_send_mail`

In the plugin file contact-form-to-any-api/includes/class-cf7-to-any-api.php, line 169, replace:

$this->loader->add_action('wpcf7_mail_sent',$plugin_admin,'cf7_to_any_api_send_data_to_api');

With:

$this->loader->add_action('wpcf7_before_send_mail',$plugin_admin,'cf7_to_any_api_send_data_to_api');

This makes the API call fire before CF7 determines success, giving you a chance to intercept the result.

Step 2: Add a Filter to Check the API Response and Change the Message

In class-cf7-to-any-api-admin.php, after line 634, add logic that checks the API response and hooks into wpcf7_display_message when an error condition is met:

if($result) {
    $api_response = json_decode($result, true);
    if(in_array("400", $api_response)){
        add_filter('wpcf7_display_message', 'change_submission_msg', 10, 2);
        function change_submission_msg($message, $status){
            if('mail_sent_ok' == $status){
                $message = 'We are unable to proceed with your request. The email address you entered is already on our server.';
            }
            return $message;
        }
    }
}

Important caveat: The developer noted that the plugin has "no plan to include such validation in our plugin" at the time of that thread. This workaround modifies core plugin files. Plugin updates will overwrite these changes. You must reapply the modification after every update, or fork the plugin.

Workaround 2: Use the `wpcf7mailsent` JavaScript Event and `add_result_props`

A cleaner approach, documented on Stack Overflow, uses CF7's add_result_props method to pass the API response to a JavaScript event listener.

Step 1: In Your `functions.php`, Hook into `wpcf7_before_send_mail`

add_action('wpcf7_before_send_mail', 'send_api_and_capture_response');
function send_api_and_capture_response($contact_form) {
    $submission = WPCF7_Submission::get_instance();
    if (!$submission) return;

    // Your API call logic here
    $response = wp_remote_post($api_url, $args);
    $body = wp_remote_retrieve_body($response);

    // Pass the API response to the frontend via the wpcf7mailsent event
    $submission->add_result_props(array(
        'api_response' => $body
    ));
}

Step 2: Listen for the Event in JavaScript

document.addEventListener('wpcf7mailsent', function(event) {
    if (event.detail.api_response) {
        // Display the API response to the user
        alert(event.detail.api_response);
        // Or inject it into a custom DOM element
        document.querySelector('.your-message-container').innerText = event.detail.api_response;
    }
}, false);

This method is update-safe because it uses hooks and does not modify plugin core files. It requires custom PHP and JavaScript but avoids the maintenance burden of patching the plugin directly.

Workaround 3: Use a Dedicated Plugin with Built-in Response Display

A different plugin, "Contact Form 7 to API," explicitly advertises the feature you need: "Option to show the API response body as the form message". Its documentation states: "Turn on 'Show the API response body as the form message' to show a JSON message field, or a shortened copy of any other body".

If displaying the API response to the user is a hard requirement, switching to a plugin with this feature built-in may be the most reliable path. The trade-off is migrating your existing integrations and field mappings to a different plugin.

Workaround 4: Use the Plugin's Logs for Admin-Only Visibility

If the API response does not need to be shown to the user but you need to monitor it, the plugin's Logs tab already provides this. The documentation confirms: "You can see your API response too".

This is the default behavior. It is useful for debugging and auditing but does not solve the user-facing problem. For a comprehensive breakdown of authentication errors and how they appear in logs, see this guide on Contact Form 7 API authentication errors.

The Debugging Checklist for API Response Issues

Step	Action	What It Reveals
1	Check the plugin's Logs tab	The exact API response for each submission
2	Determine if the API call fires before or after CF7 success	Check the hook in `class-cf7-to-any-api.php`
3	Check if the API returns errors but CF7 still shows success	Compare log entries to user reports
4	Decide if the response needs user visibility	If yes, choose a workaround above
5	Test the workaround with a forced API error	Verify the custom message appears

Beyond the Basics: What Nobody Tells You

The hook order matters more than the payload. Most debugging guides focus on JSON structure and authentication. But if the API call fires after CF7 has already committed to a success message, no amount of payload debugging will show the error to the user.

add_result_props is the most sustainable approach. It survives plugin updates and does not require modifying core files. The trade-off is that you must write the PHP and JavaScript yourself.

A different plugin solves this natively. If user-facing API feedback is a hard requirement for your workflow, evaluate "Contact Form 7 to API" which has a dedicated option for showing the API response body as the form message.

The logs are your first diagnostic tool. Before attempting any workaround, check the plugin's Logs tab. If the API response is there but the user does not see it, you have confirmed the visibility problem. If the logs are empty, the problem is earlier in the pipeline.

Key Takeaways

The plugin does not display API responses to users by default. The developer confirmed this limitation in a support thread: API errors are not shown as frontend validation messages.

The API call fires after CF7's success determination. This means users can see a success message even when the API rejected the submission.

The developer-provided workaround involves modifying plugin core files. This is update-unsafe. You must reapply the change after every plugin update, or use the add_result_props method with JavaScript instead.

A different plugin advertises built-in API response display. If this feature is critical, evaluate "Contact Form 7 to API" which has a dedicated option for showing the API response body as the form message.

For admin-only visibility, the plugin's Logs tab already works. Use it for debugging and auditing, but do not expect it to inform the user.

With the right workaround, you can bridge the gap between the plugin's admin-focused logging and the user's need for feedback. The add_result_props method is the most sustainable approach because it survives plugin updates.

CF7 to WhatsApp Business API via Twilio: The Complete Implementation Guide

Rahul Sharma — Wed, 28 Oct 2026 10:11:34 +0000

You want form submissions from your Contact Form 7 to arrive as WhatsApp messages. Not emails that sit unread. Not SMS that costs per message. WhatsApp messages that your team actually sees and responds to.

The "Contact Form to Any API" plugin can do this. But the setup has specific requirements that trip up most people: template approval, Base64 authentication, and Twilio's strict payload format. This guide walks through the exact configuration, the errors you will hit, and how to fix them.

The Architecture: Why This Is Not Just Another API Call

WhatsApp Business API is fundamentally different from email or SMS APIs. It enforces strict rules on who can message whom, and when.

The data flow looks simple:

CF7 Form → Contact Form to Any API → Twilio Messages API → WhatsApp Message Delivered

But the constraints are not simple. WhatsApp divides messages into two types: Session messages and Template messages. A session starts when a user messages your business first. Within that 24-hour window, you can send free-form replies. Outside that window, you can only send pre-approved templates. Since a CF7 form submission is business-initiated, you must use a template. There is no workaround.

This is the first thing most guides gloss over. If you skip template creation, your messages will fail silently or return error 63016.

Prerequisites: What You Need Before Touching the Plugin

Three things must be in place before you configure a single field in WordPress.

A Twilio account with WhatsApp enabled. You need your Account SID and Auth Token. For production, you also need a registered WhatsApp sender. The Twilio Sandbox is for testing only and expires after three days.

An approved WhatsApp message template. This is non-negotiable. You create it in Twilio's Content Template Builder, submit it for WhatsApp review, and wait for approval. Machine review typically takes minutes. Manual review can take up to 48 hours.

A clear understanding of ContentSid and ContentVariables. Twilio's modern WhatsApp API uses these parameters, not a raw Body parameter. Using Body outside a conversation window will fail with error 63016.

Step 1: Create a Template That Will Actually Get Approved

WhatsApp rejects templates for reasons that are not always obvious. Understanding the rejection criteria saves days of back-and-forth.

The most common rejection reasons according to Twilio's documentation:

Rejection Reason	What It Means	Fix
Variable at the start or end	`{{1}}, thank you` or `Hello {{1}}`	Add text before or after the variable
Adjacent variables	`{{1}}{{2}}`	Insert a word between them or combine
Non-sequential variables	`{{1}}, {{2}}, {{4}}`	Use sequential numbering
Too vague	`Hi {{1}}, thanks`	Add context about why the message exists
Newlines or tabs	Extra whitespace	Remove them
Duplicate content	Same template, different name	Modify both name and content

A template that will be approved looks like this:

Hello {{1}}, you have a new inquiry from {{2}}. Their message: {{3}}

This has context (new inquiry), sequential variables, and text before and after each placeholder. It will pass machine review quickly.

Copy the Template SID once approved. It starts with HX. You will need it for the plugin payload.

For a deeper dive into JSON structure mapping and variable handling, read this guide on Contact Form 7 JSON mapping.

Step 2: Authenticate with Base64 (The Step Everyone Gets Wrong)

Twilio uses HTTP Basic Authentication. The plugin's header field is a static textarea. PHP functions like base64_encode() do not execute here. You must encode the credentials manually.

Twilio's official recommendation is to use API Keys, not your Account SID and Auth Token, for production. However, the plugin's official Twilio guide uses Account SID and Auth Token for simplicity. For a production integration handling real customer data, create an API Key in Twilio Console and use that instead.

The encoding process:

Combine your credentials: ACCOUNT_SID:AUTH_TOKEN (or API_KEY_SID:API_KEY_SECRET)
Base64-encode the combined string
In the plugin's Request Headers field, add:

Authorization: Basic YOUR_BASE64_ENCODED_STRING
Content-Type: application/json

If you get a 401 error, the encoding is wrong. Verify there are no spaces before or after the encoded string.

For a comprehensive breakdown of authentication options, see this guide on Contact Form 7 API authentication errors.

Step 3: Build the Payload That Twilio Actually Expects

The plugin's official Twilio WhatsApp documentation provides this structure:

{
  "To": "whatsapp:[phone-number]",
  "From": "whatsapp:YOUR_TWILIO_WHATSAPP_NUMBER",
  "ContentSid": "HX_YOUR_TEMPLATE_SID",
  "ContentVariables": {
    "1": "[your-name]",
    "2": "[your-email]",
    "3": "[your-message]"
  }
}

Critical details that cause failures:

To must include whatsapp: before the phone number. Without it, Twilio returns error 63007 (channel not found).
From must be your registered WhatsApp sender, not a regular SMS number. For Sandbox testing, use whatsapp:+14155238886.
ContentVariables keys must match your template's variable count. If your template has three variables, your payload must have exactly three keys. A mismatch returns error 132000.
The number of variables in the template determines the number of ContentVariables entries. You cannot add extra variables that do not exist in the approved template.

Step 4: Test with the Sandbox Before Going Live

The Twilio Sandbox is the only way to test without a production WhatsApp sender. But it has limitations that confuse people.

Sandbox limitations:

Recipients must join your sandbox by sending join <code> to the sandbox number
Sessions expire after three days
Only pre-approved templates work (you cannot use custom templates)
One message every three seconds rate limit
Not available in the new Twilio Console; use the legacy Console

To test:

Activate the Sandbox in the legacy Twilio Console
Have your phone join the sandbox
Configure the plugin with whatsapp:+14155238886 as the From value
Use one of the Sandbox's pre-approved templates
Submit a test form and verify the message arrives

If the sandbox works but production fails, the issue is your production sender's status or template approval. Check that your sender's status is ONLINE in Twilio Console.

The Errors You Will Hit and Exactly How to Fix Them

Error 63007: Channel Not Found

What it means: The From address is not formatted correctly or is not associated with a WhatsApp sender.

Fix: Verify the From value uses the exact format whatsapp:+[number]. If using Sandbox, confirm the sandbox is activated in the same account. If using a live sender, check that the sender status is ONLINE.

Error 63016: Outside the 24-Hour Window

What it means: You are trying to send a free-form message outside the 24-hour customer service window, or you are using the Body parameter instead of ContentSid.

Fix: Use ContentSid and ContentVariables. Never use Body for business-initiated messages. This is the single most common production failure.

Error 63040: Template Rejected

What it means: The template was rejected by WhatsApp, or your payload matches a rejected template.

Fix: Check the rejection reason in Twilio Console. Common causes: vague content, non-sequential variables, placeholders at the start or end. Submit a new template with a different name. WhatsApp prevents reuse of a rejected name for 30 days.

Error 132000: Template Param Count Mismatch

What it means: The number of variables in ContentVariables does not match the template's variable count.

Fix: Count the {{1}}, {{2}}, etc. in your approved template. Your ContentVariables object must have exactly that many keys.

The Debugging Checklist

Step	Action	What It Reveals
1	Check plugin API Logs	Was a request sent? What response code?
2	Check Twilio Console > Monitor > Logs	Detailed error code and message
3	Verify template status	Is it Approved? Pending? Rejected?
4	Check `From` format	Does it start with `whatsapp:`?
5	Check `ContentSid`	Does it match your approved template?
6	Count ContentVariables	Does it match the template's variable count?
7	Verify Base64 encoding	Is the Authorization header correctly formatted?

Beyond the Basics: What Nobody Tells You

WhatsApp charges per template message, not per session message. Two-way conversations (where the user replies) are cheaper. Design your template to encourage a reply. A template like "Reply YES to confirm" opens a session and reduces costs.

Template approval is not permanent. Templates can be paused or disabled if users repeatedly block or report your messages. Monitor template quality in Twilio Console. If a template is paused, messages using it will fail.

The Sandbox is not a production environment. It expires. It has rate limits. It displays the Twilio logo. Use it to validate your payload and authentication. Then move to a production sender before going live.

Beyond WhatsApp: One Form, Multiple Destinations

Once your WhatsApp integration works, you might want to send the same form submission to other tools: a CRM, an email marketing platform, or a help desk system.

A good connector plugin supports multiple API integrations from a single form submission. You can send a WhatsApp message via Twilio, create a CRM contact, and subscribe the user to Mailchimp, all from one CF7 submission. For a cost comparison, see this article on Zapier vs a dedicated API plugin.

Key Takeaways

WhatsApp Business API requires pre-approved templates. There is no free-form workaround for business-initiated messages. Create and approve a template before configuring the plugin.

ContentSid and ContentVariables are mandatory. The Body parameter will fail with error 63016 outside a conversation window.

Base64 encoding must be done manually. The plugin's header field does not execute PHP. Encode ACCOUNT_SID:AUTH_TOKEN externally.

The From value must use the whatsapp: prefix. Error 63007 is the result of forgetting this.

Test with Sandbox, but do not ship with it. Sandbox sessions expire and templates are limited. Move to a production sender before going live.

With an approved template, correctly encoded credentials, and a payload that matches Twilio's modern Content API, your CF7 form submissions will arrive as WhatsApp messages on your team's phones. No missed inquiries. No email delays.

CF7 GDPR Compliant API Integration: A Complete Implementation Guide

Rahul Sharma — Tue, 27 Oct 2026 09:51:58 +0000

You have connected Contact Form 7 to an external API. Leads flow into your CRM, contacts sync to your marketing platform, and data moves automatically. Everything works.

But if you collect data from visitors in the EU, you have a legal obligation to ensure that data transfer is GDPR compliant. The plugin that sends the data, the API that receives it, and the way you collect consent all matter.

This guide walks through the practical steps to make your CF7 API integration GDPR compliant, based on the plugin's official compliance documentation and standard GDPR requirements.

Why GDPR Compliance Matters for API Integrations

The GDPR applies whenever you process personal data of individuals in the EU. A contact form submission contains personal data: name, email, phone, message. When you send that data to an external API, you are transferring it to a third party.

Article 28 of GDPR requires a contract between you (the data controller) and the API provider (the data processor). Article 32 requires appropriate technical measures to protect the data during transfer. And the data minimization principle means you should only collect what you actually need.

If you skip these steps, you are exposed to regulatory fines, data breach liability, and reputational damage. "I didn't know the API provider wasn't compliant" does not hold up as a defense.

Step 1: Get Explicit Consent (If Required)

Not every form submission requires consent. A contact form processed under a pre-contractual basis (Article 6(1)(b)) may not need a checkbox. But if you are sending data to a marketing platform, a CRM for prospecting, or any system that uses the data for purposes beyond fulfilling the immediate request, you need explicit consent.

The consent text must be specific. A non-compliant example: "I agree to the terms."

A compliant version: "I agree to receive marketing emails from [Your Company] and understand my data will be shared with [third-party tool]. I can unsubscribe at any time."

The checkbox must be unchecked by default. The user must actively opt in. Pre-ticked boxes are not valid consent under GDPR.

Step 2: Apply Data Minimization

This is where API integrations often fail. It is tempting to map every form field to every destination. The GDPR expects you to collect and transmit only what is necessary for the stated purpose.

Ask the hard question: Does your CRM actually need the phone number if you are only sending emails? Does your marketing tool need the full message body if it only uses name and email?

With the "Contact Form to Any API" plugin, you control field mapping individually. There are no automatic data dumps where everything gets sent whether it is needed or not. For each API endpoint, review the field mappings and strip out anything that is not essential for that specific integration.

If you send the same form to multiple APIs (a CRM, a marketing tool, and a spreadsheet), review each destination separately. Each endpoint might receive data it does not actually use.

For a deeper dive into JSON structure mapping and selective field inclusion, read this guide on Contact Form 7 JSON mapping.

Step 3: Ensure Encrypted Transmission

GDPR Article 32 requires appropriate technical measures to protect personal data. For API integrations, this means two things: encryption and authentication.

All data sent to APIs must use HTTPS/TLS encryption. TLS encrypts data while it travels between your server and the API endpoint, preventing interception. If an API endpoint only accepts HTTP, that is a red flag. Do not use it for personal data.

Step 4: Use Proper Authentication

Authentication verifies that your requests are legitimate and prevents unauthorized access. The plugin supports Basic Auth, Bearer Token, and OAuth 2.0 natively.

For GDPR-sensitive integrations, prefer Bearer Token or OAuth 2.0 over Basic Auth. Basic Auth sends credentials with every request, and while TLS encrypts the transmission, the credentials are still less protected than token-based methods.

For a comprehensive breakdown of authentication options and their security implications, see this guide on Contact Form 7 API authentication errors.

Step 5: Verify Your API Provider's GDPR Compliance

You are responsible for the data you send to third parties. Before connecting to any external API, verify the provider's compliance posture.

Questions to ask:

Does the provider publish a GDPR compliance statement?
Where are their data servers physically located?
Do they offer Data Processing Agreements (DPAs)?
What security certifications do they hold (SOC 2, ISO 27001)?

If the provider cannot answer these questions, find a different provider.

Step 6: Sign a Data Processing Agreement

A DPA is a legally binding contract between you (the controller) and the API provider (the processor). Article 28 of GDPR requires this arrangement whenever a processor handles personal data on your behalf.

Most major CRMs and marketing platforms offer standard DPAs. You typically sign them through the provider's settings or legal portal. If a provider does not offer a DPA, that is a serious compliance gap.

The DPA should specify:

What data the processor handles
Why and for how long
The processor's security obligations
How sub-processors are managed
Data transfer safeguards if data leaves the EU

Step 7: Handle Cross-Border Data Transfers

If your API provider stores or processes data outside the EU/EEA, you need additional safeguards. These include adequacy decisions (where the European Commission has deemed a country's data protection laws sufficient) or Standard Contractual Clauses (SCCs) for countries without adequacy status.

The US has adequacy through the Data Privacy Framework for certified companies. If your API provider is US-based, verify that they are certified under this framework before sending EU personal data.

Step 8: Set Retention Periods

GDPR's storage limitation principle means you cannot keep personal data longer than necessary. There is no universal retention period in the regulation. It depends on your purpose.

Define and document how long you keep form data. If someone inquired about a product two years ago and never responded to follow-up, do you still have a legitimate reason to keep their data? If not, delete it.

The plugin's API logs should also be considered. These logs may contain personal data from API requests. Review your log retention settings and ensure they align with your data retention policy.

The GDPR Compliance Checklist for CF7 API Integrations

Step	Action	GDPR Reference
1	Add explicit consent checkbox (unchecked by default) for marketing/prospecting data	Art. 6(1)(a), Art. 7
2	Map only necessary fields to each API endpoint	Art. 5(1)(c)
3	Ensure API endpoint uses HTTPS/TLS	Art. 32
4	Use Bearer Token or OAuth, not Basic Auth, for sensitive data	Art. 32
5	Verify API provider's GDPR statement and server locations	Art. 28
6	Sign a Data Processing Agreement with the provider	Art. 28
7	Verify adequacy or SCCs for cross-border transfers	Art. 44-49
8	Set and enforce data retention periods	Art. 5(1)(e)
9	Review API log retention settings	Art. 5(1)(e)

Beyond GDPR: One Form, Multiple Destinations

Once your GDPR-compliant integration works, you might want to send the same submission to other tools: a CRM, an email marketing platform, or a help desk system.

A good connector plugin supports multiple API integrations from a single form submission. You can create a CRM contact, subscribe the user to Mailchimp, and send an SMS via Twilio, all from one CF7 submission. For a cost comparison, see this article on Zapier vs a dedicated API plugin.

Key Takeaways

GDPR compliance is not optional for EU data. If you collect data from EU visitors and send it to an API, you need consent (where applicable), encryption, a DPA, and data minimization.

Data minimization is where most integrations fail. The plugin lets you map fields individually. Use that control. Do not send everything to every endpoint.

The plugin supports GDPR-compliant authentication. Bearer Token and OAuth 2.0 are available natively. Prefer these over Basic Auth for sensitive integrations.

Verify your API provider before connecting. A provider without a DPA or a clear GDPR statement is a compliance risk you do not need to take.

Sign the DPA before you go live. It is a legal requirement, not a formality.

With explicit consent, minimal field mapping, encrypted transmission, and a signed DPA, your CF7 API integration can be both functional and compliant. The plugin provides the technical tools. The compliance work is yours to complete.

CF7 to Copper CRM Not Creating Leads: A Complete Troubleshooting Guide

Rahul Sharma — Mon, 26 Oct 2026 08:57:59 +0000

You have built a Contact Form 7 form. You have connected it to Copper CRM through the "Contact Form to Any API" plugin. You have entered your API key and mapped the fields. And yet, when a user submits the form, no lead appears in your Copper CRM.

This is a frustratingly common problem. The good news? The issue is almost always one of four things, and each has a clear fix. This guide walks through the exact debugging process, common error patterns, and verified solutions.

Understanding the Data Flow

When a user submits your CF7 form with Copper lead creation enabled, here is what should happen:

User submits form → Plugin captures data → POST request sent to Copper API → Lead created

When it breaks, the failure happens at one of the last two stages. Your first diagnostic tool is the plugin's API Logs page. It shows whether a request was sent, the exact JSON payload, and the response from Copper. If no request appears in the logs, the problem is on the WordPress side. For a deeper breakdown of that specific scenario, see this guide on Contact Form 7 data not reaching the API.

Failure #1: The Endpoint URL Is Wrong

What you see: No lead is created. The API logs show a 404 Not Found error, or a successful request that creates a Person instead of a Lead.

Why it happens: Copper separates People and Leads into distinct API endpoints. The plugin requires you to manually enter the endpoint URL. If you paste the People endpoint instead of the Leads endpoint, the plugin will create a Person record, not a Lead.

The fix:

Verify your endpoint URL in the plugin settings. For creating leads, it must be:

https://api.copper.com/developer_api/v1/leads

The People endpoint is /people. The Leads endpoint is /leads. These are not interchangeable.

How to verify: After submitting a test form, check your Copper account. Navigate to the Leads section. If no new lead appears, the endpoint is wrong.

Failure #2: The Authentication Headers Are Missing or Incorrect

What you see: Copper returns a 401 Unauthorized or 403 Forbidden error. No lead is created.

Why it happens: Copper requires three specific headers for API authentication. The plugin provides a static textarea for request headers. If any of these are missing or incorrectly formatted, authentication fails.

The fix:

In the plugin's Request Headers field, add all three required headers:

X-PW-AccessToken: YOUR_API_KEY
X-PW-Application: developer_api
X-PW-UserEmail: your-login-email@example.com
Content-Type: application/json

Key details:

X-PW-AccessToken: Your Copper API key, generated from Profile → Email Settings & Templates.
X-PW-Application: Must be exactly developer_api. This is not your application name; it is a fixed value required by Copper.
X-PW-UserEmail: The email address you use to log in to Copper. This must match exactly.

How to verify: After saving, submit a test form. Check the plugin's API Logs. A 200 OK response means authentication succeeded.

For a comprehensive breakdown of authentication errors across different APIs, see this guide on Contact Form 7 API authentication errors.

Failure #3: The Required "Name" Field Is Missing

What you see: Copper returns a 400 Bad Request error. The response mentions a missing required field.

Why it happens: Copper requires a name field to create a lead. Without it, the API rejects the request.

The fix:

Step 1: Verify your mapping. In the plugin's JSON Payload section, ensure at least one CF7 field is mapped to the Copper name field.

Step 2: Use a hidden field if needed. If your form does not have a natural field for the lead name, add a hidden field with a default value:

[hidden lead-name default:get "Website Lead"]

Step 3: Check the payload structure. Your JSON should look like:

{
  "name": "[your-name]",
  "email": {
    "email": "[your-email]",
    "category": "work"
  }
}

Copper's email field uses a nested object with email and category properties. The category is typically work.

For a deeper dive into JSON structure mapping, read this guide on Contact Form 7 JSON mapping.

Failure #4: The Payload Structure Is Incorrect

What you see: Copper returns a 400 Bad Request error with a message about invalid fields or unexpected structure.

Why it happens: Copper's API expects a specific JSON structure. Sending flat key-value pairs instead of the expected nested format will cause the request to fail.

The fix:

Step 1: Start with a minimal payload. Use only the required fields:

{
  "name": "[your-name]",
  "email": {
    "email": "[your-email]",
    "category": "work"
  }
}

Step 2: Add fields one at a time. Once the minimal payload works, add additional fields like phone_numbers, company_name, or title. Test after each addition.

Step 3: Use the correct field names. Copper's Lead object supports fields like name, email, phone_numbers, company_name, and title. Field names must match exactly.

Step 4: Check the Content-Type header. Ensure your request includes:

Content-Type: application/json

The Debugging Checklist

Work through this sequence every time a lead fails to create:

Step	Action	What It Tells You
1	Check the plugin's API Logs	Was a request sent? What response code came back?
2	Verify the endpoint URL	Does it target `/leads`, not `/people`?
3	Check all three auth headers	Are X-PW-AccessToken, X-PW-Application, and X-PW-UserEmail present?
4	Confirm `name` field is mapped	Is the required field present in the payload?
5	Test with minimal payload	Hardcode a `name` value to isolate mapping issues.
6	Inspect the JSON structure	Is `email` a nested object with `email` and `category`?

Beyond Leads: Creating Related Records

Once you can create leads reliably, you may want to create related records. Copper's data model connects these objects:

Lead → Person: When a lead is qualified, it can be converted to a Person.
Person → Opportunity: Opportunities represent deals and are associated with People.

Copper also supports an upsert endpoint for leads (/leads/upsert), which matches on email and updates existing records instead of creating duplicates. This is useful if you want repeat submissions to update the same lead rather than creating multiple records.

Beyond Copper: One Form, Multiple Destinations

Once your Copper integration works, you might want to send the same submission to other tools: a different CRM, an email marketing platform, or a help desk system.

A good connector plugin supports multiple API integrations from a single form submission. You can create a Copper lead, add the contact to HubSpot, and send an SMS via Twilio, all from one CF7 submission. For a cost comparison, see this article on Zapier vs a dedicated API plugin.

Key Takeaways

Copper separates People and Leads into distinct endpoints. Using /people instead of /leads creates the wrong record type.

Three authentication headers are required. X-PW-AccessToken, X-PW-Application (fixed value developer_api), and X-PW-UserEmail must all be present and correct.

The name field is required for lead creation. Ensure it is mapped and never empty.

The email field uses a nested structure. Use {"email": {"email": "...", "category": "work"}} rather than a flat string.

Start with a minimal payload. Hardcode the name value first. Once that works, add additional fields one at a time.

With the correct endpoint, all three authentication headers, and a properly structured payload containing the required name field, your CF7-to-Copper integration will create leads reliably.

CF7 to Keap (Infusionsoft) Not Adding Contacts: A Complete Troubleshooting Guide

Rahul Sharma — Fri, 16 Oct 2026 07:15:43 +0000

You have built a Contact Form 7 form. You have connected it to Keap (formerly Infusionsoft) through the "Contact Form to Any API" plugin. You have entered your API credentials and mapped the fields. And yet, when a user submits the form, no contact appears in your Keap CRM.

Understanding the Data Flow

When a user submits your CF7 form with Keap contact creation enabled, here is what should happen:

User submits form → Plugin captures data → API request sent to Keap → Contact created

When it breaks, the failure happens at one of the last two stages. Your first diagnostic tool is the plugin's API Logs page. It shows whether a request was sent, the exact JSON payload, and the response from Keap. If no request appears in the logs, the problem is on the WordPress side. For a deeper breakdown of that specific scenario, see this guide on Contact Form 7 data not reaching the API.

Failure #1: The Infusionsoft Field Prefix Is Missing

What you see: The plugin's logs are empty, or Keap returns an error. The form submits successfully, but no contact is created.

Why it happens: Older CF7-to-Infusionsoft integrations require a specific field naming convention. Every form field that should be sent to Infusionsoft must be prefixed with infusionsoft-. If your CF7 field is named your-email but the integration expects infusionsoft-email, the data never reaches the API.

The fix:

Step 1: Rename your CF7 fields. In the CF7 form editor, ensure every field you want to send to Keap uses the infusionsoft- prefix.

For example:

[text* infusionsoft-first-name placeholder "First Name"]
[email* infusionsoft-email placeholder "Email"]
[tel infusionsoft-phone placeholder "Phone"]

Step 2: Update your field mappings. In the API plugin's mapping configuration, match the prefixed CF7 field names to the Keap API parameters.

Step 3: Test with a minimal form. Create a simple test form with only infusionsoft-first-name and infusionsoft-email. Submit it and check Keap for the new contact.

Important context: If you are using the "Contact Form to Any API" plugin rather than a dedicated Infusionsoft add-on, you may be building the JSON payload manually. In that case, the prefix requirement does not apply, but the field mapping to Keap's API parameters must still be exact.

Failure #2: OAuth Authentication Is Not Configured Correctly

What you see: Keap returns a 401 Unauthorized or "Developer Inactive" error. No contact is created.

Why it happens: Keap uses OAuth 2.0 for API authentication . The API token must be valid, and the refresh token must be properly managed. A common issue is that the access token expires, and the integration cannot refresh it automatically.

A Keap developer described this exact problem: "I am creating a new access token manually and replacing daily because I can't seem to figure out this OAuth process for simple API calls" . Another user reported getting "Developer Inactive" errors when trying to use a refreshed token .

The fix:

Step 1: Verify your OAuth credentials. In Keap, navigate to Settings → API Settings. Copy your Client ID and Client Secret .

Step 2: Generate a fresh API token. According to Keap's OAuth documentation, you need to generate an API token through the developer portal .

Step 3: Configure authentication in the plugin. Add the Bearer token to the Authorization header:

Authorization: Bearer YOUR_ACCESS_TOKEN

Step 4: Handle token refresh. Access tokens expire. If your plugin supports OAuth token refresh, ensure the refresh token is stored and used correctly. Note that when a refresh token is used, both the access and refresh tokens are invalidated, and a new pair is provided .

Alternative: Personal Access Tokens. Keap also supports Personal Access Tokens (PAT), which are simpler for scripting integrations. You can create a PAT from Settings → API Settings .

Failure #3: The API Payload Structure Is Incorrect

What you see: Keap returns a 400 Bad Request error. The response mentions "Field is invalid" or "Bad Request."

Why it happens: Keap's API is strict about payload structure. The contact creation endpoint expects a specific JSON format with nested objects for email addresses and phone numbers.

A Keap developer reported: "The error that I am receiving is only this: {message: 'Field is invalid'}. It does not even say what the 'Field' is that is throwing the error!" .

The fix:

Step 1: Start with a minimal payload. For Keap's REST API, a minimal contact creation payload looks like:

{
  "given_name": "[infusionsoft-first-name]",
  "family_name": "[infusionsoft-last-name]",
  "email_addresses": [
    {
      "email": "[infusionsoft-email]",
      "field": "EMAIL1"
    }
  ]
}

Step 2: Use the correct field names. Keap's API uses specific field identifiers:

given_name for first name
family_name for last name
email_addresses as an array with email and field properties
phone_numbers as an array with number and field properties

For phone numbers, you must include the field property: "field": "PHONE1" .

Step 3: Check the Content-Type header. Ensure your request includes:

Content-Type: application/json

Step 4: Use the correct endpoint. The contact creation endpoint is:

https://api.infusionsoft.com/crm/rest/v1/contacts

Note on region codes: If you include an address, the region field must use ISO region codes (e.g., US-CO for Colorado), not plain text abbreviations .

For a deeper dive into JSON structure mapping, read this guide on Contact Form 7 JSON mapping.

Failure #4: Duplicate Contact Detection Is Blocking Creation

What you see: No new contact appears in Keap. The API returns a 200 OK response instead of 201 Created.

Why it happens: Keap's API may detect that a contact with the same email address already exists and return the existing contact instead of creating a new one. This is by design, but it can appear as a failure if you are checking for a new contact.

The fix:

Step 1: Check the API response body. A 200 response means a duplicate was found and the existing contact was returned. A 201 response means a new contact was created .

Step 2: Use the duplicate_option parameter. Keap's API supports a duplicate_option parameter to control duplicate detection. Available values include EmailAndName and EmailAndNameAndCompany .

Step 3: Verify in Keap directly. Search for the contact by email address. If it already exists, the integration is working correctly — it is just updating an existing record rather than creating a new one.

The Debugging Checklist

Work through this sequence every time a contact fails to create:

Step	Action	What It Tells You
1	Check the plugin's API Logs	Was a request sent? What response code came back?
2	Verify field naming prefix	Are fields prefixed with `infusionsoft-`?
3	Check OAuth token	Is it valid and not expired?
4	Inspect the JSON payload	Does it use the correct nested structure?
5	Check for duplicates	Does the contact already exist in Keap?
6	Test with minimal payload	Hardcode values to isolate structure issues.

For a comprehensive breakdown of authentication errors across different APIs, see this guide on Contact Form 7 API authentication errors.

Beyond Contacts: One Form, Multiple Destinations

Once your Keap integration works, you might want to send the same submission to other tools: a different CRM, an email marketing platform, or a help desk system.

A good connector plugin supports multiple API integrations from a single form submission. You can create a Keap contact, add the lead to HubSpot, and send an SMS via Twilio, all from one CF7 submission. For a cost comparison, see this article on Zapier vs a dedicated API plugin.

Key Takeaways

Field naming may require the infusionsoft- prefix. Older integrations expect this convention. Rename your CF7 fields accordingly.

OAuth authentication must be configured correctly. Access tokens expire. Ensure your integration can refresh them, or use a Personal Access Token for simpler setups .

Keap's API expects a specific JSON structure. Use email_addresses and phone_numbers arrays with the correct field identifiers .

Duplicate detection may return 200 instead of 201. Check the response code and verify in Keap whether the contact already exists .

Start with a minimal payload. Hardcode a test contact first. Once that creates a record in Keap, add additional fields one at a time.

With the correct field naming, valid OAuth credentials, and a properly structured payload, your CF7-to-Keap integration will create contacts reliably.

CF7 Multi-Step Forms Not Sending All Fields to the API - Why Step Data Goes Missing

Rahul Sharma — Wed, 14 Oct 2026 10:32:08 +0000

You built a multi-step Contact Form 7 form. It works perfectly for email notifications. Every field arrives in your inbox. But when you connect it to an API through the "Contact Form to Any API" plugin, the data is incomplete. Fields from earlier steps are empty. Or worse, the API payload contains nothing at all.

This is one of the most frustrating problems in CF7 API integrations. The form works. The email works. But the API receives missing or empty data.

The good news is that this problem has a specific cause and a clear fix. This guide explains exactly why step data goes missing and how to ensure every field reaches your API.

Why Multi-Step Forms Break API Integrations

The root cause is how CF7 multi-step plugins work under the hood.

Multi-step form plugins split a single CF7 form across multiple pages. The plugin uses browser cookies to store data from earlier steps and pass it to the final submission. This works fine for email notifications because the final form submission contains all the accumulated data.

But when you connect an API integration plugin, the data flow changes. The API plugin intercepts the form submission at a different point in the process. If the multi-step plugin has not yet assembled all the step data into the final submission, the API receives only the fields from the current step.

A WordPress user described exactly this scenario: "I used to connect Contact Form 7 with Microsoft Flow using the 'CF7 to Zapier' plugin, but after changing my form using Contact Form 7 Multi-Step Forms the data isn't passed through anymore. The API works as it should be, but every field is empty."

The Cookie Storage Limit Problem

There is a second, less obvious cause: browser cookie size limits.

Multi-step plugins store step data in cookies. Cookies have a maximum size of approximately 4KB. If your form has many fields or long text inputs, the cookie can exceed this limit. When that happens, data from earlier steps is silently dropped.

A WordPress support thread documented this exact issue: "This plugin uses cookies to store the information from step to step and cookies do have a limit to the amount of information it can hold." The user reported that fields would go missing at random, sometimes step 6, sometimes step 7, and the pattern depended on how much data was entered in earlier steps.

This is why the problem appears intermittent. Short submissions work. Long submissions fail. The cookie limit is the hidden threshold.

The Hidden Field Trap

Even when the cookie storage works correctly, there is another layer of complexity: conditional fields within multi-step forms.

If your form uses conditional logic, fields that appear based on earlier selections may not be included in the final submission at all. A WordPress user reported: "The multistep can catch all the a-1 and b-1 info, but will get null value with a-2 and b-2 as there is no value display on the confirmation letter."

The solution for conditional fields in multi-step forms is to add hidden fields on the later steps that mirror the conditional field names. This ensures the multi-step plugin has a field to populate with the earlier step's data.

How the API Plugin Handles This

The "Contact Form to Any API" plugin provides conditional field logic in its API configuration settings. This allows you to define which fields appear in the API payload based on conditions.

However, the plugin cannot fix a problem that occurs before the form submission reaches it. If the multi-step plugin fails to assemble the full data due to cookie limits or missing hidden fields, the API plugin has nothing to work with.

The integration requires two layers of configuration.

Layer 1: The CF7 Multi-Step Form. Ensure all fields are properly carried through steps using hidden fields where needed.

Layer 2: The API Plugin. Configure conditional field logic to include only the fields that are actually populated for each submission path.

The Debugging Checklist

Work through this sequence when multi-step form fields are missing from the API payload:

Step	Action	What It Tells You
1	Check the plugin's API Logs	Does the logged payload show missing fields?
2	Test with a short submission	If short submissions work, the cookie limit is the issue
3	Test with a long submission	If long submissions fail, cookie storage is the bottleneck
4	Add hidden fields to later steps	Ensures conditional field data is carried through
5	Verify field names are unique	Duplicate names cause data overwrites
6	Check for page caching	Caching can prevent form data from passing correctly

For a deeper dive into JSON structure mapping and conditional payload construction, read this guide on Contact Form 7 JSON mapping.

Solutions That Work

Solution 1: Reduce Form Data Volume

If you are hitting the cookie limit, reduce the amount of data stored per step. Use shorter field names, limit textarea lengths, and avoid storing unnecessary data in the form.

Solution 2: Use Hidden Fields for Conditional Data

For conditional fields within multi-step forms, add hidden fields on the final step that mirror the conditional field names. The multi-step plugin will populate these hidden fields with the earlier step's data.

Example hidden field on the final step:

[hidden tour-bhutan]
[hidden tour-nepal]

This ensures the conditional field values are included in the final submission.

Solution 3: Switch to a Database-Backed Multi-Step Plugin

Some multi-step plugins save submission data to the WordPress database instead of cookies. This eliminates the cookie size limit entirely. The API plugin can then retrieve the full submission data from the database.

Solution 4: Disable Page Caching for Form Pages

Caching plugins can interfere with multi-step form data flow. Exclude pages containing multi-step forms from caching.

The Two-Layer Configuration Approach

Once the form data is flowing correctly, configure the API plugin's conditional logic.

In the CF7 form: Use conditional fields and hidden fields to ensure all data is captured.

In the API plugin: Use conditional field logic (Equals / Not Equals) to include only populated fields in the payload. This prevents empty fields from cluttering your CRM.

For a comprehensive breakdown of authentication and error handling across different APIs, see this guide on Contact Form 7 API authentication errors.

Beyond Multi-Step: One Form, Multiple Destinations

Once your multi-step form data flows correctly to your API, you might want to send the same submission to other tools: a CRM, an email marketing platform, or a help desk system.

A good connector plugin supports multiple API integrations from a single form submission. You can create a CRM contact, send an SMS via Twilio, and create a Zendesk ticket, all from one CF7 submission. For a cost comparison, see this article on Zapier vs a dedicated API plugin.

Key Takeaways

Multi-step plugins store step data in cookies. Cookies have a size limit. Long forms or many fields can exceed it, causing silent data loss.

Conditional fields need hidden field mirrors. Add hidden fields on later steps to ensure conditional field data is carried through to the final submission.

The API plugin cannot fix missing form data. It can only map what the form submission provides. Ensure the multi-step plugin delivers complete data first.

Page caching can break multi-step data flow. Exclude form pages from caching.

Test with short and long submissions. If short works and long fails, you are hitting the cookie limit.

With the right hidden fields, reduced data volume, and proper conditional mapping in the API plugin, your multi-step CF7 forms will deliver complete data to your API on every submission.

CF7 eCommerce Contact Form to Order/ERP API: A Complete Implementation Guide

Rahul Sharma — Tue, 13 Oct 2026 11:26:07 +0000

An eCommerce store often needs more than just a standard "contact us" form. Customers submit custom order requests, ask about bulk pricing, or inquire about product availability. Manually copying this data from form submission emails into your ERP or order management system is slow, error-prone, and does not scale.

This guide walks through how to automate the process using Contact Form 7 and the "Contact Form to Any API" plugin, sending eCommerce inquiries directly into your order or ERP API as structured records.

Why eCommerce Forms Need ERP Integration

eCommerce contact forms generate data that belongs in your order pipeline, not in an inbox.

Custom order requests. A customer filling out a form for a custom product needs that request to become an order or a quote in your system, with all the product details attached.

Bulk and B2B inquiries. Wholesale customers often submit forms with quantity requests. This data needs to flow into your ERP for pricing, inventory checks, and fulfillment planning.

Product-specific questions. When a customer asks about a specific SKU, that inquiry should be linked to the product record in your ERP for the sales team to follow up.

Without automation, every inquiry is a manual data entry task. With automation, every submission becomes a structured record ready for processing.

The Architecture: CF7 → API Plugin → ERP/Order API

The integration follows a straightforward path:

CF7 Form → Contact Form to Any API → ERP/Order API → Record Created

The plugin sends form submissions directly to your API endpoint using secure methods. It supports any endpoint that accepts POST or GET requests with structured data, including ERP systems like Odoo, Sage CRM, and custom order management APIs.

eCommerce Form Fields That Matter

A custom order or product inquiry form needs specific fields that map to your ERP or order API. Here is a field set designed for eCommerce integration:

CF7 Field	Purpose	ERP/Order API Mapping
`your-name`	Customer name	`contact_name` or `customer_name`
`your-email`	Email address	`email_from` or `customer_email`
`your-phone`	Phone number	`phone`
`product-sku`	Product identifier	`product_id` or `item_code`
`quantity`	Requested quantity	`product_qty`
`product-notes`	Customization details	`description` or `note`
`budget`	Budget indication (for quotes)	`expected_revenue`
`your-message`	Additional message	`description`

These fields map directly to standard order and ERP lead fields.

Setting Up the API Integration

Step 1: Configure the ERP/Order API Endpoint

In the "Contact Form to Any API" plugin settings, enter your ERP's API endpoint. For Odoo, this is typically the JSON-RPC or XML-RPC endpoint. For other systems, consult the API documentation for the order or lead creation endpoint.

Step 2: Map CF7 Fields to ERP Fields

The plugin provides field mapping between CF7 form fields and the API payload parameters. The mapping syntax follows this pattern:

Form Fields → API Parameters

[your-name]    → contact_name
[your-email]   → email_from
[product-sku]  → product_id
[quantity]     → product_qty

For a deeper dive into JSON structure mapping, read this guide on Contact Form 7 JSON mapping.

Step 3: Configure Authentication

ERP systems often require robust authentication. The plugin supports Basic Auth, API Key, and Bearer Token headers. For OAuth 2.0 flows, the PRO add-on handles automatic token renewal, ensuring integrations continue running without interruption.

A critical note on Basic Auth: The plugin's header field is a static textarea. PHP functions like base64_encode() do not execute when placed directly in this field. You must manually encode your credentials before pasting them into the header.

Step 4: Build the JSON Payload

The payload structure depends on your ERP's API requirements. A typical custom order or quote request payload might look like:

{
  "name": "Custom Order - [product-sku]",
  "contact_name": "[your-name]",
  "email_from": "[your-email]",
  "phone": "[your-phone]",
  "product_id": "[product-sku]",
  "product_qty": "[quantity]",
  "description": "[product-notes]",
  "type": "lead"
}

eCommerce Specific Considerations

Product SKU as Order Context

When a customer submits an inquiry about a specific product, the SKU should be included in the record. This allows your ERP to link the inquiry to the correct product for pricing, inventory, and fulfillment checks. Map a hidden CF7 field containing the product SKU to the ERP's product field.

Example hidden field in CF7:

[hidden product-sku default:get "sku"]

This captures the SKU from the page URL or a shortcode parameter.

Quantity and Pricing Logic

For bulk or custom orders, the quantity field is critical. Your ERP may need to calculate pricing based on quantity tiers or check available inventory. The API payload should include the requested quantity so the ERP can perform these calculations automatically.

Order vs Lead: Which Record Type?

Some ERP systems distinguish between a "lead" (unqualified inquiry) and an "order" (confirmed purchase). For eCommerce contact forms, the appropriate record type depends on your workflow.

Lead/Quote: If the customer is inquiring about a product and needs a price quote before committing.

Order: If the form is a direct order submission with all required payment and shipping details.

The payload's type field determines which record is created in the ERP.

Common Challenges and Solutions

ERP integrations have specific pitfalls. Here are the most common ones and how to avoid them.

Authentication Failures. ERP systems often use OAuth 2.0 or token-based access. If tokens expire or are misconfigured, data transmission halts without warning. Solution: Use token refresh logic and test authentication during setup.

ERP System Downtime. If your ERP goes offline for maintenance, form submissions cannot be delivered. Solution: Set up a retry mechanism that queues failed submissions and resends them once the ERP is back online.

Field Mapping Errors. Data gets lost or misrouted when fields between CF7 and the ERP are not accurately mapped. Solution: Perform field audits before going live.

Format Mismatches. ERPs have strict requirements for data format. Dates might need ISO standards, or dropdown values must match predefined codes. Solution: Use transformation logic to sanitize and validate data before submission.

Missing Required Fields. If the ERP API requires a field that is not mapped or is left empty, the request fails. Solution: Ensure all required fields are mapped and never empty.

The Debugging Checklist

Work through this sequence when an eCommerce form fails to create an ERP record:

Step	Action	What It Tells You
1	Check the plugin's API Logs	Was a request sent? What response code came back?
2	Inspect the response code	401 = Auth issue. 422 = Payload issue. 500 = ERP server error.
3	Verify Basic Auth encoding	Is the header manually Base64 encoded?
4	Check the endpoint URL	Does it target the correct ERP API endpoint?
5	Verify field mapping	Are all required fields mapped and populated?
6	Test with minimal payload	Hardcode values to isolate structure issues from mapping issues.
7	Test credentials in Postman	Isolates plugin issues from API issues.

For a comprehensive breakdown of authentication errors across different APIs, see this guide on Contact Form 7 API authentication errors.

Beyond ERP: One Form, Multiple Destinations

Once your ERP integration works, you might want to send the same submission to other tools: an email marketing platform, a help desk system, or a notification service.

A good connector plugin supports multiple API integrations from a single form submission. You can create an ERP record, subscribe the contact to Mailchimp, and send an SMS notification via Twilio, all from one CF7 submission. For a cost comparison, see this article on Zapier vs a dedicated API plugin.

Key Takeaways

eCommerce form data belongs in your ERP, not your inbox. Automate the flow from CF7 submission to ERP record.

Authentication is the most fragile part of the integration. Use token refresh for OAuth systems, and manually Base64-encode Basic Auth credentials before pasting them into the plugin's header field.

Field mapping must be exact. Match CF7 field names to your ERP's API field names precisely. Perform field audits before going live.

Start with a minimal payload. Hardcode a test record first. Once that works, add product-specific fields one at a time.

Plan for failures. ERP downtime and API errors will happen. Implement retry logic and monitor the plugin's logs to catch issues early.

With the correct API configuration, field mapping, and authentication, your CF7 eCommerce forms will deliver custom order requests and product inquiries directly into your ERP pipeline. No manual data entry, no missed opportunities, no delay.

CF7 Real Estate Lead Capture to CRM: A Complete Implementation Guide

Rahul Sharma — Sat, 10 Oct 2026 08:02:04 +0000

Real estate websites live and die by lead response time. When a potential buyer submits an inquiry about a property, every minute of delay reduces the chance of conversion. Manual copy-pasting from form submission emails into a CRM is not just inefficient; it directly costs you deals.

This guide walks through how to build an automated real estate lead capture pipeline using Contact Form 7 and the "Contact Form to Any API" plugin, sending every submission directly into your CRM as a structured lead.

Why Real Estate Lead Capture Needs Automation

Real estate lead generation has unique characteristics that make automation essential.

Volume and urgency. A single property listing can generate dozens of inquiries per day. Each inquiry needs a timely response. Manual processing cannot scale.

Structured data requirements. Real estate leads need specific fields: name, email, phone, property ID, inquiry type (schedule a viewing, request information, make an offer), budget range, and timeline. Sending this as an unstructured email means manual data entry into the CRM.

Team assignment. Most real estate teams route leads by property type, price range, or location. Automated CRM creation allows immediate assignment rules to fire.

The Architecture: CF7 → API Plugin → CRM

The cleanest approach for real estate lead capture uses three components:

CF7 Form (property inquiry) → Contact Form to Any API → CRM Lead Creation

This is the recommended practical approach for eliminating manual data entry. The setup is straightforward: add your CRM API endpoint in the plugin settings, map your form fields like name, email, and phone to CRM lead fields, and every form submission automatically creates a lead.

Real Estate Form Fields That Matter

A real estate inquiry form should capture more than just name and email. Here is a field set that supports CRM lead creation and routing:

CF7 Field	Purpose	CRM Mapping
`your-name`	Lead name	`contact_name`
`your-email`	Email address	`email_from`
`your-phone`	Phone number	`phone`
`property-id`	Which property they inquired about	`description` or custom field
`inquiry-type`	Schedule viewing / Request info / Make offer	`lead_source` or `description`
`budget-range`	Budget indication	Custom field
`timeline`	How soon they want to buy or rent	Custom field
`your-message`	Free-text message	`description`

These fields map directly to standard CRM lead fields: name, contact_name, email_from, phone, and description.

Setting Up the API Integration

Step 1: Configure the CRM Endpoint

In the "Contact Form to Any API" plugin settings, enter your CRM's API endpoint. For most CRMs, this is the REST API endpoint for lead creation. Consult your CRM's API documentation for the exact URL.

Step 2: Map CF7 Fields to CRM Fields

The plugin provides field mapping between CF7 form fields and the API payload parameters. The mapping works like this:

Form Fields → API Parameters

[your-name]    → contact_name
[your-email]   → email_from
[your-phone]   → phone
[your-message] → description

For real estate, you would extend this with property-specific fields like property-id, inquiry-type, and budget-range.

Step 3: Configure Authentication

Most CRM APIs require authentication. The plugin supports Bearer Token, API Key, and Basic Auth headers. Check your CRM's documentation for the required method. For a full breakdown of authentication options, see this guide on Contact Form 7 API authentication errors.

Step 4: Build the JSON Payload

The payload structure depends on your CRM's API requirements. A typical lead creation payload for real estate would look like:

{
  "name": "Website Lead - [your-name]",
  "contact_name": "[your-name]",
  "email_from": "[your-email]",
  "phone": "[your-phone]",
  "description": "[your-message]",
  "type": "lead"
}

For a deeper dive into JSON structure mapping, read this guide on Contact Form 7 JSON mapping.

Real Estate Specific Considerations

Property ID as Lead Context

When a visitor inquires about a specific property, the property ID should be included in the lead. In the CRM, this allows the sales team to see exactly which property the lead is interested in. Map a hidden CF7 field containing the property ID to a CRM custom field or the description field.

Example hidden field in CF7:

[hidden property-id default:get "property-id"]

This captures the property ID from the page URL or a shortcode parameter.

Inquiry Type Routing

Different inquiry types require different follow-up. A "schedule viewing" request needs a calendar link. A "make offer" request needs immediate escalation. By mapping inquiry-type to a CRM field, you can configure CRM automation rules to route leads appropriately.

Duplicate Prevention

Real estate leads often submit multiple inquiries. You can add a hidden CF7 field with a unique timestamp or use CRM-side deduplication rules to prevent duplicate records.

Beyond Lead Creation: What Happens Next

Once leads are in the CRM, real estate teams need:

Instant assignment. CRM automation rules assign leads to agents based on property type, location, or round-robin.

Follow-up sequences. Email and SMS sequences trigger based on lead source and inquiry type.

Pipeline tracking. Leads move through stages: New → Contacted → Viewing Scheduled → Offer Made → Closed.

Reporting. Which properties generate the most leads? Which agents convert best? What is the average response time?

All of these depend on clean, structured lead data entering the CRM. That is what the CF7 → API integration delivers.

Common Challenges and Solutions

Challenge	Solution
API authentication fails	Verify the correct auth method (Bearer vs API Key vs Basic)
Required fields missing	Ensure all CRM-required fields are mapped and never empty
Wrong data format	Match the payload structure to CRM API documentation
Property ID not captured	Add a hidden CF7 field populated from the page URL or shortcode parameter
Duplicate leads	Use unique identifiers or CRM-side deduplication rules

Beyond Real Estate: One Form, Multiple Destinations

Once your real estate lead capture works, you might want to send the same form submission to other tools: an email marketing platform, a help desk system, or an SMS notification service.

A good connector plugin supports multiple API integrations from a single form submission. You can create a CRM lead, subscribe the contact to Mailchimp, and send an SMS notification via Twilio, all from one CF7 submission. For a cost comparison, see this article on Zapier vs a dedicated API plugin.

Key Takeaways

Real estate lead capture requires structured data, not email text. Map name, email, phone, property ID, and inquiry type to CRM fields.

The CF7 → API → CRM architecture eliminates manual data entry. Every form submission creates a CRM lead automatically.

Field mapping is the core configuration. Match CF7 field names to your CRM's API field names exactly.

Start with a minimal payload. Hardcode a test lead first. Once that creates a CRM record, add property-specific fields one at a time.

CRM automation depends on clean data. Assignment rules, follow-up sequences, and reporting all require structured lead fields from the form.

With the correct API configuration, field mapping, and property-specific context, your CF7 real estate forms will deliver leads directly into your CRM pipeline. No manual data entry, no missed inquiries, no delay.

DEV Community: Rahul Sharma

CF7 to Monday.com Item Not Appearing in Board: A Complete Troubleshooting Guide

Why Monday.com Says "Success" When the Item Is Invisible

Failure #1: The API Token Belongs to a Different User

Failure #2: The Column IDs in the Payload Are Wrong

Failure #3: The Payload Structure Is Wrong for Monday's GraphQL API

Failure #4: The Board ID Is Wrong or the Token Lacks Board Access

The Debugging Checklist

Beyond the Board: One Form, Multiple Destinations

Key Takeaways

CF7 to HubSpot Deal Not Created: Why It Happens and How to Fix It

Why HubSpot Does Not Create Deals from Form Submissions

Failure #1: You Are Targeting the Contacts Endpoint, Not the Deals Endpoint

Failure #2: The Deal Stage or Pipeline ID Is Wrong

Failure #3: The Workflow That Should Create Deals Is Not Firing

Failure #4: The Contact Has No Associated Company

The Debugging Checklist

Beyond Deals: One Form, Multiple Destinations

Key Takeaways

CF7 Form Data Validation Before Sending to API: A Complete Implementation Guide

Why CF7's Built-in Validation Is Not Enough

The Solution: Validate Before the API Call Fires

Approach 1: Custom Validation Filters (Legacy Method)

Approach 2: Schema-Woven Validation (Modern Method)

Validating Against the API Before Submitting

Conditional Validation: Only Validate When Necessary

The Critical Timing Question: Before or After the API Call?

The Debugging Checklist for Validation Issues

Key Takeaways

CF7 to Salesforce Custom Object Not Created: A Complete Troubleshooting Guide

Why Custom Objects Are Different from Standard Objects

Failure #1: The Endpoint URL Is Missing the __c Suffix

Failure #2: The Field Names Are Missing the __c Suffix

Failure #3: The User Lacks Permission to Create Records on the Custom Object

Failure #4: The OAuth Token Does Not Have the Correct Scope

The Debugging Checklist

Beyond Custom Objects: One Form, Multiple Destinations

Key Takeaways

CF7 API Response Not Showing to User: Why It Happens and How to Fix It

Why the Plugin Hides API Responses from Users

The Consequence: Users See Success When the API Failed

Workaround 1: Hook into wpcf7_before_send_mail and Inject a Custom Message

Step 1: Change the Hook from wpcf7_mail_sent to wpcf7_before_send_mail

Step 2: Add a Filter to Check the API Response and Change the Message

Workaround 2: Use the wpcf7mailsent JavaScript Event and add_result_props

Step 1: In Your functions.php, Hook into wpcf7_before_send_mail

Step 2: Listen for the Event in JavaScript

Workaround 3: Use a Dedicated Plugin with Built-in Response Display

Workaround 4: Use the Plugin's Logs for Admin-Only Visibility

The Debugging Checklist for API Response Issues

Beyond the Basics: What Nobody Tells You

Key Takeaways

CF7 to WhatsApp Business API via Twilio: The Complete Implementation Guide

The Architecture: Why This Is Not Just Another API Call

Prerequisites: What You Need Before Touching the Plugin

Step 1: Create a Template That Will Actually Get Approved

Step 2: Authenticate with Base64 (The Step Everyone Gets Wrong)

Step 3: Build the Payload That Twilio Actually Expects

Step 4: Test with the Sandbox Before Going Live

The Errors You Will Hit and Exactly How to Fix Them

Error 63007: Channel Not Found

Error 63016: Outside the 24-Hour Window

Error 63040: Template Rejected

Error 132000: Template Param Count Mismatch

The Debugging Checklist

Beyond the Basics: What Nobody Tells You

Beyond WhatsApp: One Form, Multiple Destinations

Key Takeaways

CF7 GDPR Compliant API Integration: A Complete Implementation Guide

Why GDPR Compliance Matters for API Integrations

Step 1: Get Explicit Consent (If Required)

Step 2: Apply Data Minimization

Step 3: Ensure Encrypted Transmission

Step 4: Use Proper Authentication

Step 5: Verify Your API Provider's GDPR Compliance

Step 6: Sign a Data Processing Agreement

Step 7: Handle Cross-Border Data Transfers

Step 8: Set Retention Periods

The GDPR Compliance Checklist for CF7 API Integrations

Beyond GDPR: One Form, Multiple Destinations

Failure #1: The Endpoint URL Is Missing the `__c` Suffix

Failure #2: The Field Names Are Missing the `__c` Suffix

Workaround 1: Hook into `wpcf7_before_send_mail` and Inject a Custom Message

Step 1: Change the Hook from `wpcf7_mail_sent` to `wpcf7_before_send_mail`

Workaround 2: Use the `wpcf7mailsent` JavaScript Event and `add_result_props`

Step 1: In Your `functions.php`, Hook into `wpcf7_before_send_mail`