The error looks the same every time:
{
"code": "rest_no_route",
"message": "No route was found matching the URL and request method.",
"data": { "status": 404 }
}
But the causes are completely different depending on your setup. Across multiple WordPress support threads, developers have hit this error from four separate root causes that look identical in the browser console. This post covers all four so you can identify and fix yours in one pass.
What rest_no_route Actually Means
rest_no_route is WordPress telling you it received an HTTP request to a URL that does not match any registered REST API route. It is a routing failure, not an authentication failure, not a plugin failure, and not a CF7 failure.
WordPress's REST API router receives the request and looks through its registered routes for a match. When nothing matches, it returns this 404. The cause is always something that prevents the URL from reaching the correct route handler.
Cause 1: Wrong Form ID in the URL
This was the resolution in the most-viewed thread on the topic. A developer was testing the feedback endpoint in Postman using this URL:
/wp-json/contact-form-7/v1/contact-forms/fc7114d/feedback
The CF7 plugin author's reply was direct: fc7114d is not a contact form ID. CF7 form IDs are integers, not alphanumeric strings.
The correct URL format is:
POST /wp-json/contact-form-7/v1/contact-forms/123/feedback
Where 123 is the integer ID of your specific CF7 form. Find it in the WordPress admin under Contact, Contact Forms. The form ID appears in the URL when you open the form for editing: post=123.
If you are following a tutorial or building a headless Next.js integration, make sure the form ID you are using is the actual integer ID of a real form on your site, not a placeholder or slug.
Cause 2: WP Rocket Caching the REST API Response
This was the cause in two separate threads. A developer reported that CF7 forms stopped submitting suddenly with the rest_no_route error. When they disabled WP Rocket, the forms worked immediately. Re-enabling WP Rocket brought the error back.
WP Rocket can cache REST API responses under certain configurations. When a cached 404 response for the feedback URL is served instead of the live WordPress router handling the request, rest_no_route appears even though the route exists and is correctly registered.
Fix: In WP Rocket settings, go to Advanced Rules and add the CF7 feedback URL pattern to the "Never Cache URLs" list:
/wp-json/contact-form-7/(.*)
Also check WP Rocket's CDN settings if you use one. Some CDN configurations cache API responses at the edge level, which requires an edge rule to bypass caching for /wp-json/ paths.
Cause 3: .htaccess or Nginx Misconfiguration
A plugin author response in one thread identified this directly: the rest_no_route error can be caused by Apache mod_rewrite rules or an Nginx server block that is not correctly passing requests to WordPress's REST API handler.
For Nginx servers, the REST API requires this location block:
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ /wp-json/ {
rewrite ^/wp-json/(.*)$ /index.php?rest_route=/$1 last;
}
Without the second block, Nginx does not know how to route /wp-json/ requests to WordPress's PHP handler. Requests fall through to a 404 at the server level before WordPress even sees them.
For Apache, re-saving your WordPress permalinks usually regenerates the .htaccess file with the correct rewrite rules. Go to Settings, then Permalinks, and click Save Changes without changing anything.
One developer in the forums reported that re-saving permalinks temporarily fixed the issue but it kept returning. This is a sign of a plugin or a deployment process overwriting the .htaccess file. Check whether any deployment script or security plugin regenerates .htaccess without the correct WordPress rewrite rules.
Cause 4: HTTP to HTTPS Redirect Intercepting the API Request
One thread showed a CORS error alongside the rest_no_route response. The actual issue was that the site had references to the HTTP version of the domain (http://) somewhere in its configuration. When CF7's JavaScript fired the feedback request over HTTPS, a redirect from HTTP to HTTPS was intercepting it and the redirect destination was serving a 404.
Check your browser's Network tab when submitting a form. If you see a redirect (301 or 302) happening before the 404, the request is being redirected somewhere it should not be. Confirm that all references to your domain in WordPress settings use HTTPS, not HTTP:
WordPress Address (URL): https://yourdomain.com
Site Address (URL): https://yourdomain.com
If these are set to HTTP, update them under Settings, General, and then clear any caches.
Confirming the Route Is Actually Registered
Before debugging any of the above, confirm that CF7's REST API route exists on your site by visiting:
https://yourdomain.com/wp-json/contact-form-7/v1/contact-forms
If you see a JSON array of your forms, the route is registered correctly and the problem is in the feedback submission specifically. If you see rest_no_route even at this URL, CF7 itself may not be active or there is a server-level routing problem blocking all /wp-json/ requests.
A Different Architecture: Skip the REST API Dependency
The rest_no_route error exists because CF7's form submission uses the REST API by default. Every caching layer, server configuration, and security plugin that touches /wp-json/ is a potential point of failure.
If your goal is to send CF7 form data to an external CRM or API, Contact Form to API handles the outbound API call from the server side on wpcf7_before_send_mail. The form submission goes through CF7's normal processing path, not through the REST API endpoint. There is no /wp-json/feedback URL for caching plugins to intercept or for server routing misconfigurations to break.
Quick Diagnosis Checklist
| Symptom | Most Likely Cause |
|---|---|
| Error in Postman with alphanumeric form ID | Wrong form ID format — use integer ID |
| Works with WP Rocket disabled | WP Rocket caching /wp-json/ — add never-cache rule |
| Intermittent error, re-saving permalinks fixes temporarily |
.htaccess being overwritten |
| Redirect visible in Network tab before the 404 | HTTP/HTTPS mismatch in site URL settings |
rest_no_route even at /wp-json/contact-form-7/v1/contact-forms
|
CF7 not active or server blocking all REST routes |
Top comments (0)