Independent API guide

Know exactly what you can automate with Playtomic

Know what the Playtomic API can do before you buy or build around it. Avoid wasted development, challenge vague vendor claims and turn the data you can access into useful club action.

Updated 5 minute readBy Pulse Club Operations
Read-onlycurrent API

No create, update or delete booking calls

90 dayshistorical data

Plus future bookings

~1/mintypical rate limit

Check the live documentation before building

Avoid paying for an automation plan built on the wrong assumptions.

What is pulling you back in
  • Vendors saying they integrate with Playtomic without explaining what that means.
  • Time lost planning workflows the public API cannot complete.
  • Booking data sitting in exports instead of driving action.
  • Technical risk hidden behind broad claims about AI and automation.
What changes with Pulse
  • A clear boundary between read-only data access and booking actions.
  • Faster technical due diligence with the right questions upfront.
  • Reliable reporting, segmentation and communication workflows built on real data.
  • Less wasted budget and a safer route from idea to live operation.

What this does for your club

The Playtomic Club API is currently a read-only booking-data interface. Playtomic documents access to the previous 90 days of bookings plus scheduled future bookings, OAuth 2.0 authentication, UTC timestamps and a typical rate limit of one request per minute. It can support reporting, CRM synchronisation, lifecycle segmentation and external communication workflows. It cannot create, update or delete a booking through the documented public API. Any product claiming to change bookings must therefore explain the separate authorised workflow it uses, how permissions are controlled and how failures are recorded.

The short answer

Playtomic's own guide describes the Club API as read-only. An integration can retrieve and analyse booking data, but the documented public API cannot create, update or delete a booking. That makes it a strong data source, not a complete remote control for the manager product.

The guide was updated on 17 August 2026. Playtomic says individual clubs can generate External API credentials in Manager under Settings and Developer Tools. Access is available to single-location clubs on Champion or Master plans and to multi-location operators where each tenant is on one of those plans.

All clubs

Apex Padel · last 30 days

£94,180 from 2,284 bookings · revenue up 8.2% vs previous period

Playtomic connected
Revenue
£94,180
Gross paid revenue
+8.2% vs previous
Bookings
2,284
Confirmed bookings
+6.1% vs previous
Active players
1,806
Players booked in period
+4.4% vs previous
Court utilisation
66%
3,410h of est. capacity
+5.2% vs previous
Booking heat mapDay of week by hour
101112131415161718192021
Mon
31
24
28
23
27
33
52
59
64
50
29
12
Tue
25
29
24
19
21
23
63
69
54
51
36
16
Wed
22
31
26
20
22
24
45
49
40
35
31
7
Thu
25
29
30
26
35
44
57
61
55
63
42
20
Fri
37
50
44
48
52
58
68
66
65
70
31
15
Sat
45
43
42
34
31
36
30
34
26
21
8
6
Sun
41
44
47
39
44
51
49
53
47
36
19
11
Illustrative dashboard built from fictional Apex Padel data. It demonstrates an analytical use of booking data, not a screenshot of the Playtomic API or a customer account.

What the API exposes

The documented booking feed includes booking IDs and timestamps, court information, player details, communication preferences and payment information. Playtomic presents CRM synchronisation, analytics, member communications, loyalty and facility integrations as common uses.

  • OAuth 2.0 authentication with a client ID and client secret.
  • Historical bookings from the previous 90 days and scheduled future bookings.
  • A maximum request range of 365 days.
  • UTC timestamps that the integration must convert to the club's local timezone.
  • A typical rate limit of one call per minute, subject to the current documentation.

What read-only means for club automation

Read-only access is enough to identify lapsed players, measure court utilisation, sync a CRM or trigger an outbound message. It is not enough on its own to confirm a new reservation or alter an existing one through the public endpoint.

Any vendor promising actions inside Playtomic should explain its method, safeguards and failure handling clearly. Ask which actions use the public Club API, which use a different authorised workflow, how permissions are scoped and where every change is logged. Pulse combines Playtomic data with controlled action workflows agreed with the club; it does not describe the read-only API as writable.

A practical due-diligence checklist

  • Confirm every location has the required Playtomic subscription tier.
  • Keep the client secret on the server and rotate it if exposed.
  • Design around the rate limit rather than treating the feed like a live event stream.
  • Document timezone conversion before calculating occupancy or revenue by hour.
  • Separate data-reading claims from booking-changing claims in vendor evaluations.

Which architecture fits each job?

JobPublic Club API fitImportant constraint
Occupancy reportingStrongConvert UTC and define sellable capacity before calculating utilisation
CRM or lifecycle syncStrongRespect communication preferences and the 90-day historical window
Campaign audience creationStrongThe API can identify behaviour; messaging permission is a separate decision
Live availability assistantLimitedA rate-limited booking feed is not the same as a live availability or reservation endpoint
Create or change a bookingNot supported publiclyRequires a separately explained and authorised workflow

A safer implementation sequence

  1. Confirm plan eligibility and create credentials in Playtomic Manager under Settings and Developer Tools.
  2. Store the client secret only on the server and document who can rotate it.
  3. Pull a narrow booking range first, preserve the raw UTC timestamp and add a separate local-time field.
  4. Create idempotent imports so retrying a request cannot duplicate records or campaign eligibility.
  5. Monitor token expiry, rate-limit responses, data freshness and gaps before using the feed for decisions.
  6. Add action workflows only after the read model is reliable and each non-API action has explicit permission and logging.

Important: Playtomic states that there is no separate test environment. Keep initial queries narrow and avoid using an unverified feed to trigger customer messages.

How this guide was prepared

This page was checked line by line against Playtomic's own Club API guide dated 17 August 2026. Claims about access, authentication, data range, timezones, rate limits and write capability come from that primary source. Interpretations about architecture and vendor due diligence are Pulse's analysis and are labelled as such.

About the authorPulse Club Operations

The team building and reviewing Pulse workflows with padel clubs. Product claims are separated from illustrative demo data, and changeable platform claims are checked against current primary documentation.

Sources and verification

Product capabilities, policies and prices can change. These sources were checked on 29 August 2026.

Frequently asked questions

Is the Playtomic API read-only?

Yes. Playtomic's current Club API guide says the API can retrieve and analyse booking data but cannot create, update or delete bookings.

How much Playtomic history is available?

The current guide says the previous 90 days of booking data plus future bookings are available, with a maximum request range of 365 days.

Which Playtomic plans include API access?

Playtomic documents access for Champion or Master plans. For multi-location access, each tenant needs an eligible plan.

Can the public API change a booking?

No. The documented public Club API does not create, update or delete bookings. Ask any automation vendor to explain separately how it performs actions.

See Pulse live

See what this looks like in your club.

Try the public front desk, or spend 30 minutes mapping Pulse to your WhatsApp, Playtomic setup and busiest workflows.