Requests and rules

Learn how to add auth headers and a request body to a check, and how content rules judge the response.

This page explains the three fields that turn a URL check into a real probe: request headers, a request body, and content rules. Headers and bodies apply to HTTP, Keyword, API, and Scheduler monitors. Content rules apply to the HTTP family.

#Request headers

Add up to 4 headers to every check the monitor sends. The form's auth picker covers a Bearer token and an API key header, and the custom mode covers everything else. Header names may contain letters, digits, and dashes, up to 64 characters, and must be unique. Values may be up to 1024 characters with no line breaks. Hop-by-hop names such as Host, Connection, and Content-Length are refused.

Header values are secrets and are treated as such: encrypted at rest and write-only. The settings sheet never shows a stored value. Leave the headers section untouched and the stored values keep being used. Add rows and the new list replaces all of them.

Every check sends a User-Agent of UptimeX-HealthCheck/1.0 (+https://uptimex.co), so you can allowlist the probe or exclude it from analytics.

#Request bodies

POST, PUT, PATCH, and DELETE checks can carry a body of up to 8 KB. It is sent as application/json unless you set your own Content-Type header. GET and HEAD refuse a body. In the form, Form mode builds a flat JSON object from key and value rows, and Raw mode takes the body as you type it.

The body is stored as plain text, since it is a test payload you read and edit. Real secrets belong in the encrypted headers.

The body is sent with every scheduled check

A monitor with a write method fires that write on your interval, all day, every day. Point it at test data or a dedicated test route, never at anything that changes real customer state.

#Content rules

Content rules judge the response body, so a 200 that renders an error page still fails. A monitor can have up to 4 rules, and all of them must pass. Because they need the body, a HEAD monitor with rules is checked with GET, and the check follows redirects to reach the final page.

Rule	Passes when	Plan
Body contains	The body includes the text you set.	All plans
Body is missing	The body does not include the text you set.	All plans
JSON field	The body is valid JSON, the field at your path exists, and it matches the expected value if you set one.	Pro, Team

The mechanics that matter:

Text rules are case-sensitive and match the raw body, up to its first 64 KB. Dashboard does not match dashboard. There are no wildcards and no regular expressions.
A JSON path is a dot path, such as data.status. A numeric segment indexes an array: items.0.id. Leave the expected value empty and the rule only requires the field to exist. The expected value is compared as text, so true matches a boolean true.
If the body is not valid JSON, a JSON rule fails, which is itself a useful signal from an API.
Every rule is evaluated on every check, and the activity log records each failing rule with what the body contained.

Pick text that is boring and load-bearing. A copy tweak should not page you, so avoid marketing lines, and avoid anything a signed-out visitor never sees.

#Putting it together

An authenticated health probe over the API, with an auth header and a rule pinned to the real health signal:

Shell

curl -X POST https://api.uptimex.co/v1/monitors \
  -H "Authorization: Bearer upk_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "api",
    "url": "https://api.example.com/health",
    "request_headers": [{ "name": "Authorization", "value": "Bearer service-token" }],
    "content_rules": [{ "type": "json_field", "path": "status", "equals": "ok" }]
  }'

The same configuration is available field for field in the dashboard form and over MCP.

#What's next?

Check types: where each rule type fits.
The monitor page: reading a rule's verdict on the page.
Errors: the invalid_headers, invalid_body, and invalid_content_rules codes.