Page changes.
Your workflow.

Authenticate with a scoped token

On Pro, open Dashboard → API access. Create a named token, choose its permissions and expiry, and copy it once. Send it in the Authorization: Bearer header. Tokens are stored as hashes and cannot be retrieved again.

export PAGEFLUXER_API_BASE="https://pagefluxer.com/api/v1"
# Set PAGEFLUXER_API_TOKEN using your server's secret manager.
curl --fail-with-body "$PAGEFLUXER_API_BASE/monitors?limit=20" \
  -H "Authorization: Bearer $PAGEFLUXER_API_TOKEN"

API base URL: https://pagefluxer.com/api/v1. Use a token from your PageFluxer account. Website cookies do not authenticate this API.

Tokens expire after 1–365 days; the dashboard offers 30, 90 and 365 days. Revocation blocks subsequent requests. Pro access is checked on every request, so a downgrade disables existing tokens without changing their secrets. Accepted work may finish after revocation. Re-upgrading restores access for tokens that have not expired or been revoked.

Use tokens from your own server. Keep them out of public JavaScript, URLs, repositories and browser extensions. V1 grants no cross-origin browser access. Never send third-party website passwords, cookies, or login sessions.

Endpoint reference

Request and response bodies are JSON. Success responses contain data; lists also contain meta. The downloadable OpenAPI document includes request fields, target schemas, response schemas and error responses.

Confirm the cloud capture before saving

1. POST /previews with a public URL and load_mode of html or browser.
2. Choose up to three targets from the captured elements. Optionally call POST /previews/{preview_id}/evaluate to inspect the extracted values without loading the page again.
3. POST /monitors with the preview ID, targets, schedule and an Idempotency-Key. The cloud capture seeds the baseline; it does not send an initial change alert.

Previews expire after 15 minutes; only the three most recent captures per account are retained. Use a fresh preview and expected_version from the monitor’s config_version when editing targets, loading method or schedule. Metadata, status, and email/webhook flags can be patched directly. URLs cannot be changed; create a new monitor for a different URL.

Alert rules match the builder: text changes or phrase transitions; price changes, drops or crossing below a threshold; becoming available/unavailable; and new matching links. Prices use an explicit currency and decimal format. Threshold strings always use a dot, such as 30.00. Price observation values are integer minor units: USD 29.00 is 2900. Missing or unknown values are check issues, never invented prices or stock states. Monitor setup guide →

Predictable account limits

Request limits are shared across tokens. Authenticated, authorized calls count, including reads, polling, replays and rejected input. Successful GET response bodies also share a 100 MiB/day transfer allowance (before HTTP compression) to bound history-export costs. Inspect X-Read-Bytes-Day-Remaining. A rejected read is not charged bytes, but still uses a request. Monthly monitoring, notification and preview allowances remain separate. API access adds no check credits and causes no automatic overage charges. Use GET /usage to inspect both.

Inspect X-RateLimit-Remaining, X-RateLimit-Reset (Unix seconds), and the daily limit headers. On 429, wait at least Retry-After seconds. The minute window begins with the account’s first request after its previous window expires. Daily counters reset at 00:00 UTC; monthly counters reset on the first of the month at 00:00 UTC.

Lists are newest first. Follow meta.next_cursor unchanged with the same filters until it is null. Results are not a frozen snapshot: newly arriving changes appear at the start of a fresh traversal, and deleted/expired items may disappear. Deduplicate change IDs. Higher throughput, bulk API operations and team administration are planned for Business and are not part of v1.

Request a check, then poll its receipt

POST /monitors/{monitor_id}/checks takes {} and an Idempotency-Key. A 202 response means accepted into the existing worker schedule, not that the page has been fetched. Poll the Location URL no more than once per minute.

• The monitor must be active. Its fastest plan interval and failure backoff still apply.
• Manual requests and the website’s check button share the same daily allowance. An already-pending request returns its existing receipt without another daily charge.
• The worker reserves a normal HTML/browser check when it claims the work. Failures use that allowance; pre-fetch cancellations and capacity deferrals refund it.
• Daily manual-request slots are not refunded after acceptance, including expiry or cancellation.
• Service capacity, website backoff and other account work can delay execution. Queued receipts expire after 30 minutes; receipts remain readable for seven days.
• A successful check can produce no change. Read monitor status and change history separately. Pausing, deleting, changing targets, or losing Pro access can cancel pending requests.

Safe retries and useful errors

{
  "error": {
    "code": "insufficient_scope",
    "message": "Token requires monitors:write.",
    "request_id": "3f390fd5-6c91-4d4f-8b42-a9dbba26a7d0"
  }
}

Use a unique Idempotency-Key for each logical monitor creation or manual-check request. Reuse the same key and JSON body when retrying a timeout. Successful responses are retained for 24 hours; reusing a key with different content returns 409. Keys are scoped to the account and operation. JSON object property order does not matter.

Only committed successes are retained. A transaction rollback does not consume the key. Replaying a creation after deleting its monitor returns the original ID; it does not recreate the monitor. A manual-check replay returns the original acceptance response: fetch its receipt for current status. After 24 hours, a key can be treated as a new request.

Preview loading is not idempotent: retrying it can use another preview. Evaluation reuses the saved capture. For transient failures, back off with jitter and respect Retry-After; do not automatically repeat non-idempotent preview loads.

401 means invalid credentials, 403 means plan/scope restrictions, 404 means unavailable or unowned data, 409 means a conflict or exhausted account allowance, 422 means invalid settings, and 503 means temporary service unavailability. Unsupported fields and query parameters are rejected. Include error.request_id when contacting support; never send your API token.