If a Cloudflare rewrite works for an integration but fails for an ordinary browser visit with error 1037, compare the inputs each request supplies. Cloudflare could not evaluate the rewrite expression; an undefined value is one documented cause. The failing request and matching expression are more useful evidence than a general WordPress plugin reset.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Find the input the rewrite cannot evaluate
| Observation | What to inspect | Useful next check |
|---|---|---|
| Only browser requests fail | A header supplied by the integration | Compare whether the expression references an absent field |
| Failures began after a rule change | The matching condition and new expression | Check whether the rule now includes requests without required inputs |
| All expected inputs exist | Other expression evaluation problems | Keep the exact expression and request context for an administrator |
Find the input the expression expects
Build an input checklist: list each field read by the expression, where it comes from, and its behavior when absent. In the documented example, http.request.headers["x-source"][0] expects a first header value. That is an illustration to compare against your actual expression, not a requirement to add that header to every visitor request.
Keep the exact address that failed and note whether it came from a browser, an application, or an automated request. Review the rewrite rule matching that address and list the inputs used by its expression. Header references and other request-specific values deserve a closer look than fixed text.
Cloudflare’s documentation gives an example that reads the first X-Source header value. If the request does not include that header, the reference can be undefined and the expression can fail. The example is useful because it shows why a rule can pass a test from one application while failing for a visitor opening the same URL.
Your own rule may use a different field, so treat the example as a pattern to investigate. The error does not prove that X-Source is involved, nor does it identify the exact expression element on its own.
Compare two requests that take the same route
A useful comparison keeps the page and rule the same while changing as little else as possible. For instance, a request from an integration might carry a custom source header, while a normal browser navigation does not. If only the integration succeeds, that difference gives the administrator a concrete question to test.
Record which input is present, absent, or unexpectedly formatted in each request. Avoid copying private cookies or authorization values into shared notes. A sanitized description of the relevant field is enough for an initial review.
Also check the matching condition. A rule intended only for integration requests may have been applied to all visitors on that path. In that case, expanding the data supplied by every visitor is less sensible than correcting the scope of the rule.
Handle the missing-input case deliberately
Choose the intended outcome first. If a label is optional, the ordinary page may be the right fallback. If it selects a protected integration route, a missing label must not be replaced with a privileged value. Use supported conditions or expressions for the relevant Cloudflare feature and retain the previous rule so the change can be reversed.
The corrected rule needs a defined behavior when the expected input is absent. Depending on the purpose, that may mean applying the rewrite only to requests that carry the necessary information, or using a supported fallback expression. Review the syntax for the Cloudflare feature you are using before deploying a change.
Suppose the rule sends known integration traffic to a specific internal path. A browser visit without the integration’s label might belong on the ordinary WordPress page instead. Leaving that request untouched could preserve the intended experience more clearly than inventing a label and forwarding every visitor to the integration path.
If the missing information is essential to a protected workflow, a fallback should not silently grant access or select a privileged destination. Define the expected behavior with the application owner and keep the change limited to the rule involved.
Verify both the normal and exceptional requests
Retest the request that originally failed and the request that previously worked. Both matter: a rule that now accepts browser visits but breaks the integration has only moved the problem. Include an example with the input missing so that the repaired behavior is exercised directly.
Check the destination page as well as the disappearance of 1037. A rewrite can return a successful response from the wrong path, making a superficial test look reassuring. The page content and relevant application behavior should match what each request was intended to receive.
When handing the issue to an administrator, include the rule identifier, the sanitized expression, the failing path, and which required input was absent. If all referenced inputs are defined and the error continues, keep the failure evidence for a deeper expression review rather than assuming that every 1037 has the same cause.
Documenting the missing-input case beside the rule makes future changes easier. It tells the next maintainer why ordinary visitor requests and integration requests need different treatment, without leaving them to rediscover the original error.
Reference: Cloudflare error 1037 documentation.
Confirm missing-input handling stays reliable
- The originally failing request returns its intended content.
- The previously working integration still follows its intended route.
- An absent input has a deliberate, documented outcome.
- The support record identifies the rule and relevant field without private credentials.