Pricewatcha API, SDKs and MCP Server for Developers and AI Agents

No credential required for catalog search, product detail, price history and async track/poll. Without a key those endpoints use anonymous rate limits. Send an API key to use the higher per-account track, search and product-read quotas.

Requires auth

Protected API v1 endpoints (alerts, webhooks, authenticated track callbacks) use:

Authorization: Bearer pwk_live_…

Do not use the login session token for alerts, webhooks or other API v1 calls once you have an API key.

See Access model for which routes are public vs authenticated.

Rate limits

Current limits (indicative)

The following limits apply and may change without notice.

Send Authorization: Bearer pwk_live_… on POST /track, GET /search, or product reads to use the authenticated tier. Those endpoints remain available without a key at the anonymous limits.

Client identity: anonymous limits are keyed by client IP. Behind Cloudflare the API prefers CF-Connecting-IP over X-Forwarded-For so edge proxy IPs are not treated as distinct clients. The hosted MCP server forwards a stable X-Pricewatcha-Client-Id (OAuth token hash, else connecting-IP hash) with a shared proxy secret so MCP callers are not all bucketed under one egress IP. Authenticated track, search and product-read quotas are keyed by account (owner_id), not IP.

Monitor X-RateLimit-Remaining and honor 429 with exponential backoff. X-RateLimit-Policy names which window the headers refer to (track, track_hourly, track_daily, track_concurrent, job_read, search, search_hourly, search_daily, read, read_hourly, or read_daily).

Track quotas are counted from persisted jobs (api_track_jobs by client key or account), so they apply across multiple app instances. A long-poll that holds the HTTP connection for ~25s still counts as one track job when created — sequential tracks spaced farther apart than 60s will not trip the burst window, but hourly/daily and concurrent caps still apply.

Agents should prefer: start track → poll GET /jobs/{id} with backoff (not every 1–2s) → read product/history once complete. Retrying POST /track with the same URL while that job is still queued/processing reuses the existing job and does not consume another concurrent slot. Jobs left queued/processing longer than the scrape timeout (default 600s) are failed so slots cannot leak across deploys.

Search and product-read quotas are in-memory per app instance (not shared across Railway replicas the way track jobs are). Authenticated callers still get the higher per-account windows. Polling the same catalog queries on a short interval will still trip the hourly/daily search windows.

Exact numbers may change without notice (env overrides: API_V1_TRACK_*, API_V1_TRACK_AUTH_*, API_V1_JOB_READ_*, API_V1_READ_*, API_V1_READ_AUTH_*, API_V1_SEARCH_*, API_V1_SEARCH_AUTH_*).

Headers

When rate limiting is active, responses may include:

HTTP 429

When limited, the API returns 429 Too Many Requests with a JSON body:

{
  "error": {
    "code": "rate_limited",
    "message": "Rate limit exceeded (track daily). Try again later.",
    "http_status": 429,
    "retry_recommended": true,
    "retry_after_seconds": 3600
  }
}

Agent guidance: honor 429, wait until retry_after_seconds / X-RateLimit-Reset, and reduce poll frequency on job status endpoints. Prefer spreading tracks over time rather than bursting near the hourly/daily caps. Anonymous 429 responses mention that an API key raises quotas.

Operators can receive an email when hourly/daily/concurrent track limits or hourly/daily search and product-read limits trip (cooldown per client; see API_V1_RATE_LIMIT_ALERT_*).

Abuse and IP restrictions

Sustained abuse of anonymous daily quotas (track, search, or product reads — for example exhausting the daily limit on several days from the same IP) may trigger an in-app restriction, not only 429.

1. Notice (grace period). API calls still succeed. Responses include X-Pricewatcha-Restriction: notice and X-Pricewatcha-Restriction-Message with the pending-block warning. Rate limits still apply.
2. Block. If there is no reply, the IP is blocked. Further calls return HTTP 403 with error.code access_restricted.

Email info@pricewatcha.com to discuss terms or restore access. Do not retry until access is restored. Retries will not lift the restriction.

Changelog

All notable changes to the public API contract, SDKs and MCP server in this repository.

Package / release versioning uses 0.1.x. HTTP API paths remain /api/v1.

0.1.6 - 2026-08-26

Changed

• Search rate limits: GET /api/v1/search now has its own stacked quotas, separate from generic catalog reads: anonymous ~20 / 60s, ~60 / hour, ~200 / day; authenticated (API key) ~40 / 60s, ~180 / hour, ~1000 / day, keyed per account. Polling the same queries on a short interval returns HTTP 429 with X-RateLimit-Policy search, search_hourly, or search_daily.
• Product read rate limits: GET /products/{id} and /price-history keep the per-minute burst and add hourly/daily caps: anonymous ~120 / 60s, ~180 / hour, ~600 / day; authenticated ~240 / 60s, ~540 / hour, ~3000 / day.
• Abuse notices: exhausting the anonymous daily search or product-read quota (search_daily / read_daily) counts toward the same IP strike threshold as track_daily. After several distinct UTC days the client is asked to contact info@pricewatcha.com (X-Pricewatcha-Restriction: notice); if there is no reply the IP is blocked. Default restriction scope is all of /api/v1 except health/discovery.

0.1.5 - 2026-08-24

Changed

• Search matching: GET /api/v1/search?q= uses case-insensitive token AND (all terms must appear; order does not matter) instead of requiring the full query as one contiguous substring. Hyphens, slashes and similar punctuation are normalized to spaces (Darth-Vader ≡ Darth Vader, 1/6 ≡ 1 6). Contiguous phrase matches still rank higher. Minus-prefixed exclude terms are unchanged.

0.1.4 - 2026-08-23

Added

• Directional price alerts: notify_on_drop and notify_on_rise on POST/PATCH/GET /api/v1/alerts. Either flag is enough — a numeric threshold is no longer required.
• MCP alert tools: create_price_alert, list_price_alerts, get_price_alert, update_price_alert, delete_price_alert (API key required). Same directional flags as the HTTP API.
• Google product category: google_product_category_id and google_product_category_name on GET /api/v1/products/{id}, GET /api/v1/search (and MCP get_product / search_products / completed track jobs). Always present in responses (null when unset); search needs no extra query parameter.
• Search exclude terms: GET /api/v1/search?q= accepts minus-prefixed tokens (e.g. iPhone 15 -cover -hülle) to drop products whose name, shop or URL contains those terms. Case-insensitive. limit applies after exclusion.
• Abuse / IP restrictions: repeated anonymous daily-limit hits may start a grace/notice period (API still works, X-Pricewatcha-Restriction: notice), then a block (403 access_restricted). Contact info@pricewatcha.com.

0.1.3 - 2026-08-17

Changed

• Track concurrent slots: queued/processing jobs older than the scrape timeout are failed automatically (startup + POST /track), so a deploy or hung worker cannot block a client forever.
• Same-URL retries: a second POST /track for a URL that already has an in-flight job for that client returns the existing job_id instead of HTTP 429.

0.1.2 - 2026-08-13

Changed

• Track rate limits: anonymous quotas stay at ~2 concurrent / 10 per minute / 40 per hour / 80 per day. Client identity prefers CF-Connecting-IP (then True-Client-IP, then X-Forwarded-For) so Cloudflare edge IPs are not separate buckets.
• Authenticated track quotas: API key or login session on POST /track receives higher per-account limits (~4 concurrent / 20 per minute / 120 per hour / 400 per day). The account is stored on the track job even without a callback.
• MCP callers can be rate-limited by a stable forwarded client id instead of a shared egress IP.

0.1.1 - 2026-06-28

Changed

• Removed Public Preview branding from API docs, OpenAPI spec and SDKs. Discovery status is available.

0.1.0 - 2026-06-03

Initial release of the public API, official SDKs and remote MCP server.

Added

• GET /api/v1/health
• GET /api/v1: discovery document
• POST /api/v1/track: async ingestion (200, bounded long-poll ~25s)
• GET /api/v1/jobs/{jobId}
• GET /api/v1/products/{productId}
• GET /api/v1/products/{productId}/price-history
• GET /api/v1/search?q=
• GET /api/v1/openapi.json
• Demo catalog: demo_iphone_15_pro, demo_galaxy_s24
• Rate limit response headers on v1 endpoints
• API keys: POST /api/keys, GET /api/keys, DELETE /api/keys/{id} (pwk_live_...)
• Alerts: POST/GET/PATCH/DELETE /api/v1/alerts (API key required)
• Webhooks: full CRUD at /api/v1/webhooks, test delivery, delivery logs (API key required)
• Official MCP server: remote HTTP at https://mcp.pricewatcha.com (no API key for MCP connection)
• Docs: API key as default credential; login session token for headless key bootstrap only

Notes

• Read endpoints remain open without authentication; API keys required for alerts and webhooks
• Endpoints and fields may change without notice

POST /api/v1/track submits a product URL and waits up to ~25 seconds (long-poll). No API key is required. Send Authorization: Bearer pwk_live_… to use higher per-account track quotas.

• Fast shops: status: "completed" with full product in the same response
• Slow shops: status: "running" + job_id: poll GET /api/v1/jobs/{jobId} until completed or failed
• Repeat POST /track for the same URL while a job is in flight returns that job instead of starting another (and instead of a concurrent 429)

Jobs are retained for 72 hours. After expiry, GET /jobs/{jobId} returns 404: use GET /products/{productId} instead.

Typical flows

Fast shop (one call)

POST /api/v1/track → { "status": "completed", "product": { ... } }

Slow shop

POST /api/v1/track → { "status": "running", "job_id": "job_xxx", "hint": "..." }
GET  /api/v1/jobs/{jobId} → poll until terminal state
GET  /api/v1/products/{productId} and .../price-history

Track a product

curl -s -X POST "https://pricewatcha.com/api/v1/track" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://www.backmarket.de/de-de/p/example-product"}'

Response (200) when the scrape completes within the long-poll window:

{
  "job_id": "job_xxxxxxxx",
  "status": "completed",
  "product": {
    "product_id": "prod_xxxxxxxx",
    "name": "Example product",
    "shop": "Back Market",
    "current_price": 563,
    "currency": "EUR"
  },
  "error": null
}

Response (200) when still running after the long-poll timeout:

{
  "job_id": "job_xxxxxxxx",
  "status": "running",
  "product": null,
  "error": null,
  "hint": "Job still running. Call the get_job_status tool with this job_id to poll for the result."
}

Poll job status

curl -s "https://pricewatcha.com/api/v1/jobs/job_xxxxxxxx"

Completed response

{
  "job_id": "job_xxxxxxxx",
  "status": "completed",
  "product": {
    "product_id": "prod_xxxxxxxx",
    "name": "Example product",
    "shop": "Back Market",
    "current_price": 563,
    "currency": "EUR"
  }
}

Job states

Recommended client flow

1. POST /track with { "url": "..." } → 200
2. If running or queued, poll GET /jobs/{jobId} every 2–5 seconds
3. On completed, read product from the job or GET /products/{productId}
4. On failed, surface error.code; backoff before retrying

Job lookup vs. scrape failure

When polling GET /jobs/{jobId}, interpret HTTP status and body together:

A 404 is a lookup problem. A 200 with failed is a completed job whose scrape did not succeed.

Authenticated clients can receive a push when a track job finishes: use callback_url (one-off) or webhook_id (existing subscription). Mutually exclusive. Callbacks do not consume extra quota beyond the authenticated track job.

curl -s -X POST "https://pricewatcha.com/api/v1/track" \
  -H "Authorization: Bearer pwk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://www.backmarket.de/de-de/p/example-product",
    "callback_url": "https://n8n.example.com/webhook/track-done"
  }'

With callback_url, the track response may include callback_secret (whsec_…) once: same signing as subscription webhooks.

When the job finishes, Pricewatcha sends a webhook with event type track_job_completed or track_job_failed (same payload shape as other webhooks). If you do not use push delivery, you can still wait on POST /track (long-poll) or poll GET /jobs/{jobId} until the job reaches a terminal state.

SDK convenience

Official Python and TypeScript SDKs may provide track_and_wait() / trackAndWait(): a helper that calls POST /track, then polls GET /jobs/{jobId} until the job is completed or failed and returns the result. The HTTP API stays async-first; the helper only saves you from writing the poll loop yourself. See SDKs.

Deduplication

Repeated POST /track for the same URL may return completed quickly with existing intelligence.

Timeouts

Long-poll default is ~25 seconds. For slow shops, poll GET /jobs/{jobId} instead of extending the track timeout.

Search

Keyword search is case-insensitive. The query is split into tokens; a product matches when every token appears in the normalized product name, URL, platform/shop or related fields. Word order does not matter, and punctuation such as hyphens and slashes is treated as whitespace (Darth-Vader matches Darth Vader). Results cover the full Pricewatcha catalog, not only URLs submitted via POST /track.

Exact contiguous phrases still rank above other token matches when both match.

Endpoint

GET https://pricewatcha.com/api/v1/search?q=…&limit=…

Optional limit: default 50, maximum 200. Applied after exclude-term filtering.

Search is rate-limited separately from product reads. Anonymous callers get ~20 requests / 60s, ~60 / hour, ~200 / day; an API key raises that to ~40 / 60s, ~180 / hour, ~1000 / day per account. Honor HTTP 429 and X-RateLimit-Policy; see Rate limits.

q supports Google-style minus-prefixed exclude terms. q=iPhone+15+-cover+-case returns products matching both "iPhone" and "15" that do not contain "cover" or "case" in the searchable fields (case-insensitive). A lone - is ignored.

curl -s "https://pricewatcha.com/api/v1/search?q=iphone&limit=10"
curl -s "https://pricewatcha.com/api/v1/search?q=iPhone+15+-cover+-case"
curl -s "https://pricewatcha.com/api/v1/search?q=Darth+Vader+DX27"

Example response

[
  {
    "product_id": "demo_iphone_15_pro",
    "name": "Apple iPhone 15 Pro 128GB (Refurbished)",
    "shop": "Back Market",
    "product_url": "https://www.backmarket.de/de-de/p/example-iphone-15-pro",
    "current_price": 563,
    "currency": "EUR",
    "status": "active",
    "preview": true,
    "google_product_category_id": null,
    "google_product_category_name": null
  },
  {
    "product_id": "prod_a1b2c3d4e5",
    "name": "iPhone 15 Pro",
    "shop": "Swappie",
    "product_url": "https://swappie.com/de/p/iphone-15-pro/",
    "current_price": 505,
    "currency": "EUR",
    "status": "active",
    "google_product_category_id": null,
    "google_product_category_name": null
  }
]

Use product_url for direct linking without an extra GET /products/{id} call.

Results always include google_product_category_id and google_product_category_name (null when unset). You do not need an extra query parameter.

Demo catalog (no scrape required)

Preview demo products are always available for integration testing:

curl -s "https://pricewatcha.com/api/v1/products/demo_iphone_15_pro"
curl -s "https://pricewatcha.com/api/v1/products/demo_iphone_15_pro/price-history"
curl -s "https://pricewatcha.com/api/v1/search?q=iphone+15+pro"

See the demo catalog on GitHub.

Data boundaries

Catalog price intelligence (current price, history, product metadata) is available without authentication. User-specific data (accounts, emails, alert settings, private watchlists) is never exposed through the public API.

Readable fields

• product_id, name, shop/platform, product URL
• Current price, currency, last checked, status
• Price history, historical low/high, average, trend
• data_source and data_source_label when price data comes directly from a merchant feed (merchant_feed → "Direct merchant data")
• google_product_category_id and google_product_category_name on product detail and search (null when unset). Search does not require an extra query parameter.
• Demo entries may include "preview": true

Search, product detail and price history return the same fields whether the product was added via dashboard, API, MCP or demo data.

Product IDs

Use product_id from search or a completed track job for GET /products/{productId} and .../price-history.

Webhook payloads

Deliveries include product-level event data only (prices, product IDs, event type), not user emails or account details. Verify authenticity with the subscription signing secret (whsec_...); see Webhooks.

Compliance

If you build on this API, disclose to your users that prices are informational and that merchant sites are authoritative.

Errors and error codes

Non-success responses use a structured error object. Inspect error.code: do not parse free-text message values.

Shape

{
  "error": {
    "code": "invalid_url_type",
    "message": "url looks like a search or listing page (query parameter 'k')",
    "http_status": 400,
    "retry_recommended": false,
    "retry_after_seconds": null
  }
}

Public / track / catalog codes

Authentication & API keys

Alerts & webhooks

Agent guidance

• Branch on error.code, not message.
• When retry_recommended is true, use exponential backoff and respect retry_after_seconds.
• HTTP 200 on GET /jobs/{jobId} with status: "failed" is a job failure, not a transport error.

Full schemas: live GET https://pricewatcha.com/api/v1/openapi.json and the OpenAPI spec on GitHub.

Create price alerts that send email notifications and/or fire webhooks when a price moves.

Each tracked product has one alert record per user. Combine any of:

• notify_on_drop: notify on any price drop (no threshold required)
• notify_on_rise: notify on any price increase (no threshold required)
• min_threshold_price: notify when price drops to or below this value
• max_threshold_price: notify when price rises to or above this value

At least one of those four settings is required.

All endpoints require an API key in Authorization: Bearer …. Full schemas: GET https://pricewatcha.com/api/v1/openapi.json (tag alerts).

Endpoints

Create a directional alert (no threshold)

Notify whenever the price goes down — same as the dashboard Cheaper toggle:

curl -s -X POST "https://pricewatcha.com/api/v1/alerts" \
  -H "Authorization: Bearer pwk_live_YOUR_KEY_HERE" \
  -H "Content-Type: application/json" \
  -d '{
    "product_id": "prod_a1b2c3d4e5",
    "notify_on_drop": true,
    "notify_email": true,
    "name": "Any drop"
  }'

Create a threshold alert

curl -s -X POST "https://pricewatcha.com/api/v1/alerts" \
  -H "Authorization: Bearer pwk_live_YOUR_KEY_HERE" \
  -H "Content-Type: application/json" \
  -d '{
    "product_id": "prod_a1b2c3d4e5",
    "min_threshold_price": 499.00,
    "max_threshold_price": 599.00,
    "webhook_url": "https://n8n.example.com/webhook/alert",
    "notify_email": true,
    "name": "Deal range"
  }'

Example response (201):

{
  "alert_id": 76,
  "product_id": "prod_a1b2c3d4e5",
  "min_threshold_price": 499.00,
  "max_threshold_price": 599.00,
  "notify_on_drop": false,
  "notify_on_rise": false,
  "currency": "EUR",
  "webhook_url": "https://n8n.example.com/webhook/alert",
  "notify_email": true,
  "name": "Deal range",
  "is_active": true,
  "created_at": "2026-05-24T12:00:00Z",
  "updated_at": "2026-05-24T12:00:00Z",
  "last_triggered_at": null
}

List and get

curl -s "https://pricewatcha.com/api/v1/alerts" \
  -H "Authorization: Bearer pwk_live_YOUR_KEY_HERE"

curl -s "https://pricewatcha.com/api/v1/alerts?product_id=prod_a1b2c3d4e5" \
  -H "Authorization: Bearer pwk_live_YOUR_KEY_HERE"

curl -s "https://pricewatcha.com/api/v1/alerts/76" \
  -H "Authorization: Bearer pwk_live_YOUR_KEY_HERE"

Update and delete

curl -s -X PATCH "https://pricewatcha.com/api/v1/alerts/76" \
  -H "Authorization: Bearer pwk_live_YOUR_KEY_HERE" \
  -H "Content-Type: application/json" \
  -d '{"notify_on_drop": true, "min_threshold_price": null}'

curl -s -X PATCH "https://pricewatcha.com/api/v1/alerts/76" \
  -H "Authorization: Bearer pwk_live_YOUR_KEY_HERE" \
  -H "Content-Type: application/json" \
  -d '{"is_active": false}'

curl -s -X DELETE "https://pricewatcha.com/api/v1/alerts/76" \
  -H "Authorization: Bearer pwk_live_YOUR_KEY_HERE"

AI Agents & MCP

Pricewatcha exposes a remote MCP endpoint: no local installation required. Connect your AI client with the URL below. Available tools include catalog reads (get_api_status, search_products, track_product, get_job_status, get_product, get_price_history) and price alerts (create_price_alert, list_price_alerts, get_price_alert, update_price_alert, delete_price_alert). Alert tools require a Pricewatcha API key and can notify on any drop or rise without a numeric threshold.

https://mcp.pricewatcha.com

For step-by-step setup, see Claude, ChatGPT, n8n and Make below.

Claude

What it enables: Ask Claude to search for products, track prices, check price history, set alerts and manage webhooks, all in natural language, directly in Claude.ai or the Claude desktop app.

How to connect: Claude.ai (web)

Step 1: Open the Customize panel
Click Customize (sliders icon) in the left sidebar of Claude.ai or go to claude.ai/settings/connectors.

Step 2: Add a custom connector
Under Connectors, click + to add a new connector.

Step 3: Enter the MCP server URL
Enter a name (e.g. “Pricewatcha”) and paste:

https://mcp.pricewatcha.com

Click Add.

Step 4: Done
Pricewatcha appears in your connector list with read-only tools (get_api_status, get_job_status, get_product, get_price_history, search_products, list_price_alerts, get_price_alert) and write tools (track_product, create_price_alert, update_price_alert, delete_price_alert). You can now use Pricewatcha in any Claude conversation.

Step 5: Configure tool permissions (optional)
Open the connector in your connector list (or return to claude.ai/settings/connectors) and expand Tool permissions.

For each tool — or for the whole Read-only / Write group — choose when Claude may call it:

For everyday price checks and searches, set the read-only tools (or the whole read-only group) to Always allow. For track_product and alert tools, pick Always allow if you want friction-free writes, or keep Require approval if you prefer to confirm first. Alert tools need a Pricewatcha API key (pwk_live_...).

How to connect: Claude Desktop App

Same steps: Customize → Connectors → Add custom connector → paste https://mcp.pricewatcha.com. Tool permissions are configured the same way under Tool permissions in the connector settings.

Try:

• “Find me a refurbished iPhone 15 Pro under €550”
• “Track this product URL and show me the price history”
• “Set an alert for this product when it drops below €500”
• “Notify me whenever this product gets cheaper — no price target”

Note: track_product is a write tool because it creates a tracking job in the background. It does not modify or delete existing data. Alert tools (create_price_alert, update_price_alert, delete_price_alert) change your saved alerts and require an API key.

ChatGPT

What it enables: Search products, track prices, get price history, set price alerts and manage webhooks, directly in ChatGPT via MCP.

Prerequisite: Developer Mode (one-time)
Custom MCP connectors require Developer Mode: Settings → Advanced → enable Developer Mode. Available on Plus, Pro, Team, Business, Enterprise and Edu (not on the free plan). Pricewatcha tools only work while Developer Mode stays on.

Step 1: Go to Settings → Apps and click Add custom connector.

Step 2: Paste the MCP URL:

https://mcp.pricewatcha.com

Optional connector logo: PNG, max 10 KB. Download from https://pricewatcha.com/static/img/mcp/chatgpt-logo.png

Step 3: Authentication: Select OAuth. ChatGPT handles the flow; you may see a brief authorization prompt on first connect.

Step 4: Done. Example prompts:

• “Search for a refurbished iPhone 15 Pro under €550”
• “Track this product URL and show me the price history”
• “Notify me whenever this product gets cheaper — no price target”

Warning: ChatGPT may show a DEV label on unverified third-party connectors. Pricewatcha only works while Developer Mode is enabled.

n8n

What it enables: Build automated price-monitoring workflows. Trigger actions when prices change or cross your alert threshold: no coding required.

Typical use case: When a tracked product drops below your threshold → send a Telegram, Slack or email notification with product name, shop, current price and alert name.

Note: A publicly accessible URL is only required if you run n8n locally (self-hosted on your own machine). If you use n8n Cloud or a server-hosted instance, your n8n webhook URL is already publicly accessible: skip the tunnel step.

Path A: n8n Cloud or server-hosted (no tunnel needed)

1. Create a Webhook node in n8n → copy the Production URL.
2. Create a Pricewatcha alert with webhook_url set to the n8n URL (see below).
3. Done: price_alert_triggered events are delivered when thresholds are crossed.

Path B: n8n self-hosted locally (tunnel required)

1. Start a Cloudflare Tunnel: cloudflared tunnel --url http://localhost:5678 (install with brew install cloudflared on macOS).
2. Copy the tunnel URL (e.g. https://abc123.trycloudflare.com).
3. Create a Webhook node in n8n → note the path (e.g. /webhook-test/abc123).
4. Combine: https://abc123.trycloudflare.com/webhook-test/abc123.
5. Use this as webhook_url in the Pricewatcha alert.

Create a price alert with webhook delivery

Requires an API key:

curl -s -X POST "https://pricewatcha.com/api/v1/alerts" \
  -H "Authorization: Bearer pwk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "product_id": "prod_YOUR_PRODUCT_ID",
    "min_threshold_price": 600.00,
    "webhook_url": "https://YOUR_N8N_URL/webhook/YOUR_PATH",
    "notify_email": false,
    "name": "Price drop alert"
  }'

When the current price is at or below min_threshold_price, Pricewatcha sends a price_alert_triggered event with this payload shape:

{
  "event_id": "evt_...",
  "event_type": "price_alert_triggered",
  "occurred_at": "2026-05-26T20:32:07Z",
  "product": {
    "product_id": "prod_...",
    "name": "iPhone 15 Pro",
    "shop": "Swappie",
    "current_price": 559.00,
    "currency": "EUR"
  },
  "price": {
    "old_price": 559.00,
    "new_price": 559.00,
    "historical_low": 7.99,
    "historical_high": 649.00,
    "average_price": 570.44
  },
  "alert": {
    "alert_id": "77",
    "min_threshold_price": 600.00,
    "threshold_reached": "min",
    "name": "Price drop alert"
  },
  "metadata": {
    "source": "pricewatcha",
    "api_version": "v1"
  }
}

Recommended n8n workflow

1. Webhook node (trigger): receives the price_alert_triggered event.
2. IF node: filter: {{ $json.body.event_type }} equals price_alert_triggered.
3. Notification node: Email / Telegram / Slack with:
   - Product: {{ $json.body.product.name }}
   - Shop: {{ $json.body.product.shop }}
   - Current price: {{ $json.body.price.new_price }} {{ $json.body.product.currency }}
   - Alert name: {{ $json.body.alert.name }}

Test the connection

curl -s -X POST "https://pricewatcha.com/api/v1/webhooks/YOUR_WEBHOOK_ID/test" \
  -H "Authorization: Bearer pwk_live_YOUR_KEY"

Note: The test endpoint requires a webhook subscription (POST https://pricewatcha.com/api/v1/webhooks), not an alert.

Signature verification: Verify X-Pricewatcha-Signature (HMAC-SHA256) in production: see Webhook signing.

Alternative: use the HTTP Request node: GET https://pricewatcha.com/api/v1/search?q=… or GET https://pricewatcha.com/api/v1/products/PRODUCT_ID/price-history.

Make

What it enables: Same webhook-based automation as n8n: visual workflows without code.

1. Create a scenario with Custom webhook as trigger; copy the URL.
2. Create a Pricewatcha webhook subscription (same curl as the n8n guide, use your Make URL as target_url).
3. Add a Router on event_type.
4. Test with POST https://pricewatcha.com/api/v1/webhooks/{id}/test.

Make free plan: Up to 1,000 operations/month including webhooks, enough for personal price monitoring.

Smart home

Use price alert webhooks to drive automations: scenes, notifications or lighting when a tracked product hits your target price.

See Home Assistant and Loxone below.

Home Assistant

What it enables: Trigger automations when a Pricewatcha price alert fires.

Typical use case: Price below threshold → mobile notification, toggle input_boolean.good_deal or run a script.

Path A: Webhook trigger (recommended)

1. Add a Webhook trigger (e.g. webhook ID pricewatcha_price_drop → https://YOUR_HA_HOST/api/webhook/pricewatcha_price_drop).
2. Ensure the URL is reachable from the internet (Nabu Casa, reverse proxy or tunnel).
3. Create a Pricewatcha alert with that webhook_url (n8n guide shows the curl example).
4. In actions, use trigger.json.product.name, trigger.json.price.new_price, etc.

Example automation (YAML):

automation:
  - alias: "Pricewatcha price drop"
    trigger:
      - platform: webhook
        webhook_id: pricewatcha_price_drop
        allowed_methods: [POST]
        local_only: false
    action:
      - service: notify.notify
        data:
          title: "Price alert: {{ trigger.json.product.name }}"
          message: >-
            {{ trigger.json.product.shop }} ·
            {{ trigger.json.price.new_price }}
            {{ trigger.json.product.currency }}

Path B: REST sensor (poll)

rest:
  - resource: "https://pricewatcha.com/api/v1/products/prod_YOUR_PRODUCT_ID"
    scan_interval: 3600
    sensor:
      - name: "Tracked product price"
        value_template: "{{ value_json.current_price }}"
        unit_of_measurement: "EUR"

No API key required for read endpoints. Polling is simpler but less real-time than webhooks.

Signature verification: Validate X-Pricewatcha-Signature in production: see Webhook signing.

Loxone

What it enables: Poll current prices from Pricewatcha on a schedule and trigger Loxone programs when a price threshold is reached. Works with both Miniserver Generation 1 and Generation 2.

Path A — Poll current price (Virtueller HTTP Eingang)

Loxone's Virtueller HTTP Eingang (Virtual HTTP Input) fetches a URL at a configurable interval and extracts values via Command Recognition. Each extracted value becomes a Loxone input that can be used in your programs.

Gen2 — direct HTTPS (no middleware needed)

Miniserver Gen2 supports HTTPS natively and can call the Pricewatcha API directly.

Gen1 — via LoxBerry https2http Plugin

Miniserver Gen1 does not support HTTPS. Install the https2http Plugin on LoxBerry. It acts as an HTTPS proxy: LoxBerry fetches the Pricewatcha HTTPS response and serves it to Loxone over HTTP.

Step 1 — Find your product ID

Search for your product and note the product_id (format: prod_... or use a demo product like demo_iphone_15_pro):

GET https://pricewatcha.com/api/v1/search?q=YOUR+PRODUCT

Step 2 — Create a Virtueller HTTP Eingang in Loxone Config

In Loxone Config, go to Periphery → Virtual Inputs → Virtual HTTP Input.

Set the URL based on your Miniserver generation:

Set the polling interval (Abfragezyklus), e.g. 3600 seconds (every hour).

No API key or authentication required — the product endpoint is public.

Step 3 — Add Virtueller HTTP Eingang Befehle (Command Recognition)

For each value you want to extract, add a Virtueller HTTP Eingang Befehl (Virtual HTTP Input Command) to the input. Command Recognition searches the raw JSON response for a pattern and extracts a value.

The Pricewatcha product API returns JSON like this:

{
  "product_id":"prod_...",
  "name":"Apple iPhone 15 Pro 128GB (Refurbished)",
  "shop":"Back Market",
  "current_price":563.0,
  "currency":"EUR",
  "status":"active"
}

Add one Befehl per value you need:

Pattern syntax reference:

• \v — extracts a numeric value at this position
• \a — extracts a text value (reads until next ")
• \i...\i — skip/ignore text between markers (use to navigate to the right position in the JSON)

Step 4 — Connect to your program

Each Befehl output is a numeric or text value you can use directly in Loxone programs:

• Connect current_price to a Threshold Switch (Schalter mit Schwellwert) → fires when price drops below your target
• Connect the threshold switch output to a Push Notification, lighting scene, or any other Loxone action

Path B — Real-time price alerts via LoxBerry

Loxone cannot directly receive Pricewatcha webhooks because Pricewatcha requires a publicly reachable HTTPS endpoint, and the Miniserver is typically behind NAT without a public IP. This applies to both Gen1 and Gen2.

LoxBerry acts as the middleware: it receives the Pricewatcha webhook and forwards the data to the Miniserver via MQTT.

The receiver URL depends on your LoxBerry version:

Step 1 — Create a Pricewatcha API key

Create an API key on this page (requires login). Alerts and webhooks require authentication.

Step 2 — Create a Pricewatcha price alert pointing to LoxBerry

curl -s -X POST "https://pricewatcha.com/api/v1/alerts" \
  -H "Authorization: Bearer pwk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "product_id": "prod_YOUR_PRODUCT_ID",
    "min_threshold_price": 500.00,
    "webhook_url": "http://YOUR_LOXBERRY_IP/system/tools/mqtt/receive.php",
    "notify_email": false,
    "name": "Price drop alert"
  }'

Step 3 — Configure LoxBerry MQTT Subscriptions

In the LoxBerry MQTT configuration, subscribe to topic rcvr/#. The incoming JSON payload is parsed automatically. Map the relevant fields (e.g. event_type, price/new_price) to Loxone Virtual Inputs via MQTT subscriptions.

Step 4 — In Loxone Config

Connect the Virtual Input (triggered by the MQTT subscription) to your notification or automation program.

SDKs

Official Python and TypeScript client libraries live in sdks/ on GitHub.

They support the async track → poll → read workflow. Use the OpenAPI schema or plain HTTP from any other language.

Python

from pricewatcha import Pricewatcha

client = Pricewatcha()  # public endpoints, no key needed

# With an API key (alerts, webhooks, …)
client = Pricewatcha(api_key="pwk_live_YOUR_KEY")

Install from the Python SDK on GitHub. Setup: sdks/python/README.md.

TypeScript

import { PricewatchaClient } from "@pricewatcha/sdk";

const client = new PricewatchaClient();  // public endpoints, no key needed

const authedClient = new PricewatchaClient({ apiKey: "pwk_live_YOUR_KEY" });

Install from the TypeScript SDK on GitHub. Setup: sdks/typescript/README.md.

Client generation

Generate clients in other languages from the OpenAPI spec or live GET https://pricewatcha.com/api/v1/openapi.json (OpenAPI Generator, Speakeasy, Kiota and similar tools).