API access

Where it stands

There is no public API yet. The app talks to a set of callable endpoints that are private, unversioned, and changed whenever it suits us, which is exactly what you do not want to build against.

We are opening a read-first API to a handful of clubs before committing to it publicly. If you have a real use for one, we would rather design it with you than guess.

What it is for

The requests we actually get are narrow and sensible. Put the next few dates on a club's own website. Push meals into a shared calendar. Pull a club's ledger into whatever a treasurer already keeps the accounts in. Let a venue's booking system open a date automatically.

All of those are a host wanting their own club's data somewhere else. That is the shape of the thing: scoped to one club, authorised by a host of that club, and useless for anything outside it.

What it will not do

There will be no endpoint that lists clubs, searches across them, or reads anything from a club you are not in. A club you have not been let into is indistinguishable from a club that does not exist, and an API is not going to be the hole in that.

Nothing to do with payments, because we do not process any. Balances are a record between a host and a member, and the API treats them as read-only history.

No bulk export of member contact details. Hosts see who is in their club; that is not the same as a machine-readable list of everyone's email address.

The shape we are planning

An HTTPS API returning JSON, authorised with a key a host generates for one club and can revoke at any time. Read endpoints first: the schedule, a meal and its menu, seat counts, the club's ledger. Writes, if they come, will start with opening a date.

Rate limits will be generous for the traffic a single club produces and firm enough that a key cannot be used to crawl. Every key is attributable to a club, and a host can see what it has been doing.

Asking for early access

Write to api@ladleclub.com from the address on your account, say which club you host and what you want to build. Tell us what data you need and where it is going. If it fits the read-first shape above, we will send you a key and the current documentation.

We will also say no sometimes, and say why. A vague "exploring integrations" is not enough to justify opening a door into somebody's private club.