Polymarket Data with n8n

• HTTP Request node → GET /v1/markets/{slug}/books with start_ts/end_ts/resolution=250ms and the API key in headers.
• Query parameters generated from previous-node output let one workflow serve N markets.
• Destination nodes: Google Sheets, Postgres, Slack (alerts on spread/crossed), or a Parquet write.
• Error-handling path: retry on 429/5xx with backoff; the API is monotonically timestamped so replays are idempotent.

• One workflow per cadence (5m, 15m, 4h) rather than one giant graph; the parameters differ, the schema does not.
• Alert logic in one Code node: flag spread > threshold or crossed rows, then post to Slack/telegram.
• Store the last pulled timestamp in an n8n variable so resumption after restart backfills exactly the gap.
• Books, prices, and metrics come back over the same endpoints at the same 250ms resolution, so a dashboard needs one schema, not three.

A self-hosted n8n instance gives you scheduling, retries, and destination integrations without maintaining a scheduler process or API glue. For teams that already run n8n, Polymarket flows are an hour of work.

For laptop-only research, the Python SDK is nicer; for something that must run unattended, n8n is the honest pick.

The canonical flow is five nodes: Schedule, HTTP Request (books endpoint), Code (compute spread and flags), If, and a Slack/Telegram node for threshold hits.

Resume logic is the part people skip: store the last seen timestamp in n8n variables, pass start_ts from it, and the workflow self-heals after restarts or retries.

A week of 5-minute pulls for one BTC market should sum to 2,016 rows; mismatch points at timezone math on start_ts or a missed page boundary, not at the data.

The same workflow shape works for the metrics endpoint, so liquidity and volume panels refresh on the same clock without a second pipeline.

n8n industrializes the pull: schedule, retry, and destination all live in the flow editor, so a Polymarket scrape that ran as a notebook cell becomes an owned piece of infrastructure with audit logs.

The pattern that stays honest is the cursor: every run stores the last ts it saw, and replays are safe because the API sequences monotonically — you are not leaving gaps or double-counting frames.

One workflow per cadence (5m, 15m, 4h) keeps the retry policy and destinations readable; the query params differ, the 250ms schema never does.

Build the first flow with a single market and a 5-minute schedule; two days later you have 576 rows, the retries have logged, and the alert path is tested end to end.

Test the restart path explicitly: stop the flow, let it miss one window, restart it, and confirm the cursor backfills exactly the gap — that single exercise de-risks the whole automation.

n8n makes the Polymarket pull a thing you can hand to an operator rather than a thing that runs on a laptop. The hour you invest in a scheduled flow with a cursor, retries, and an alert path pays back the first time a market reprices overnight and the Slack post arrives before the morning coffee.

The workflow you keep is short: schedule, request, transform, branch, notify. Everything else — backfill scripts, junction tables, embedded dashboards — accumulates in the data warehouse where it belongs, and the flow stays reviewable in five minutes.

Start with the free tier for the pilot and let the retry log be the evidence that the design holds; when the flow has survived a week of alarms without a missed frame, promote it to the plan that fits weekly volume.

• API data guide
• Data download
• Order book data
• MCP server