> ## Documentation Index > Fetch the complete documentation index at: https://padelapi.org/docs/llms.txt > Use this file to discover all available pages before exploring further. # Padel API vs Scraping > Padel API vs building your own scraper: normalization, WebSockets, canonical IDs, and unified coverage across FIP, Premier Padel, and WPT. If you are building anything with professional padel data, you have two real options: stand up your own scraper across the official sources, or consume a single normalized API. Both can produce a working prototype. The difference shows up in **week 4**, when source HTML changes, a player's name suddenly has a new spelling across two tournaments, and a fixture you were polling silently disappears from the calendar. This guide is a technical comparison of the two paths. *** ## The hidden cost of "I'll just scrape it" A first scraper for a single source is a weekend project. The hard part is not writing it — it is keeping it useful for a year. Anyone who has run a scraper in production has paid some version of this tax: * **Source HTML changes** with no notice. Selectors break, fields move, layouts get re-rendered. Every change is an outage. * **Failures are silent.** A broken selector returns an empty list, which looks identical to "nothing happened today". You find out from a user. * **Player names are not stable.** The same player appears as `"Juan Lebrón"`, `"Juan Lebron"`, and `"J. Lebrón Chincoa"` across tournaments — and sometimes across rounds of the same tournament. Without entity resolution, you are silently splitting one player across multiple records. * **Tournaments rename, merge, get cancelled, or shift dates.** If you keyed your data by name or by URL slug, every change is a manual reconciliation. * **Live data is hostile to polling.** Fast polling gets your IP blocked; slow polling shows a stale scoreboard. * **Three sources, three integrations.** FIP, Premier Padel, and the World Padel Tour archive each have their own structure, IDs, and quirks. You write — and maintain — three scrapers, three parsers, three deduplication layers. * **Historical data is gone the moment it leaves the homepage.** A season-long backfill means hoping the data still exists somewhere you can reach. None of this is fundamentally hard. It is just a long list of small things that need to keep working forever. *** ## Side-by-side comparison | | Build your own scraper | Padel API | | ----------------------------- | ------------------------------------------------ | ------------------------------------------------------------------ | | **Time to first usable data** | Days to weeks per source | One `curl` after signup | | **Sources covered** | One per scraper you write | FIP, Premier Padel, and WPT in a single schema | | **Schema** | Whatever the source HTML happens to be that week | Stable JSON, consistent across sources | | **Player identity** | Manual deduplication on name strings | Numeric IDs, canonical via `302` redirects | | **Tournament identity** | Breaks on rename/merge/cancellation | Stable IDs, redirects on merges, explicit `cancelled` status | | **Live scores** | Polling with the risk of IP blocks | Pusher WebSocket channels, push on every point | | **Historical depth** | Whatever the source still exposes today | Multi-season archive available on day one | | **Aggregated stats** | You compute them yourself | Career, pair, head-to-head, and per-round endpoints out of the box | | **Failure mode** | HTML 200 with broken markup | Conventional HTTP status codes, rate-limit and redirect headers | | **Operational cost** | Yours, forever | None — covered by the API | *** ## Why normalization is the moat The biggest gap between a scraper and this API is **normalization** — the work of turning three different sources into a single coherent dataset. **Cross-source unified schema.** A tournament from Premier Padel and a tournament from the legacy WPT archive come back with the same field names, the same enum values for level and status, and the same structure for matches, players, and pairs. One schema covers a 2023 WPT 1000 and a current P1. **Stable IDs and canonical redirects.** Numeric IDs are the primary key. When reality changes, the API tells you: * A tournament gets renamed → same ID. * Two tournaments merge → the deprecated one returns `302` pointing at the canonical one. * Two player records turn out to be the same person → the deprecated player returns `302`, and match history is consolidated under the surviving ID. * A tournament is cancelled → it disappears from list endpoints but remains addressable by ID with `status: "cancelled"`. Your sync job follows redirects and updates a foreign key. Compare to maintaining a fuzzy-matching layer over a stream of name strings. See [Data Synchronization](/docs/guides/data-synchronization) for the recommended sync strategy. **Computed endpoints.** Some of the most interesting questions in padel — head-to-head records, pair chemistry, win rate in finals, season-on-season form — are aggregations over the entire match history, not facts you can scrape. The API ships them as endpoints: * [`/players/{id}/stats`](/docs/api-reference/player/show-player-stats) — career win rate, titles, finals, best round, with `after_date` / `before_date` / `round` filters. * [`/pairs/{p1}-{p2}/stats`](/docs/api-reference/pair/show-pair-stats) — how a specific duo performs together. * [`/matches/{id}/stats`](/docs/api-reference/match/show-match-stats) — set-by-set serve, return, break point, and streak metrics. *** ## Real-time without the polling tax If your product shows live scores, scraping is where the gap widens fastest. Aggressive polling gets you blocked; gentle polling makes the scoreboard look broken. The API exposes a Pusher WebSocket channel per match, pushed on every point, with the same JSON shape as the REST `live` endpoint. No polling loop, no IP rotation, no captcha handling. See the [WebSockets guide](/docs/websockets) for the full client setup. *** ## When scraping does make sense To be fair: rolling your own pipeline is rational when you need a **specific data point that is not exposed by any API**, and you are willing to own the pipeline forever for the sake of that one field. If what you need is tournaments, draws, matches, results, players, pairs, point-by-point live data, and aggregated stats across FIP, Premier Padel, and WPT, the API already covers it. *** ## Get started Authenticate and run your first request in under a minute. Keep a local copy in sync — including redirects and merges. Push live point-by-point updates without polling.