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

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

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.