Ask here, not by email.

Sign in with Google and one is issued immediately, on the free plan. There is no card and no trial clock. The key appears on your account page and stays visible there, so you never have to store it somewhere else in a hurry.

Almost always one of three things. It was rotated from your account page, in which case the old one stopped the moment the new one appeared. Or the header is wrong: it must be X-API-Key. Or you are getting a 403 rather than a 401, which is a plan refusal and not an authentication problem at all.

No. There is one key per account and its entitlement is read on every request, so an upgrade widens what the key you already hold can reach, the same day, with nothing to reissue.

Not at the moment. One account, one key, which is what makes an upgrade take effect without a reissue. If you need to separate environments, tell us what you are doing and we will say honestly whether it is on the roadmap.

Nine times out of ten because the jurisdiction never published it. Data coverage shows which fields exist in which country, counted from the archive rather than declared. Official ratings are on about three quarters of British runners and a few percent of French ones, and no provider has what was not released.

America publishes the placings and nothing below them, so runners outside the first four come back with position: null. It is not a gap in our data. If your work counts beaten runners, American racing cannot support it.

No, and we never will. They do not exist in this dataset at any point in its history, in any jurisdiction. If your model needs in-running fractions this is the wrong feed, and no plan changes that.

No. Starting price, an opening price where one was published, and the tote. We are not a price aggregator and will not become one. Price movement exists on British and Irish runners and essentially nowhere else.

Every response carries data_as_of, which is when the serving database was last written. Results land within minutes in Britain and Ireland and can take longer elsewhere, because the delay is the jurisdiction publishing rather than us fetching.

Check /v1/meta/coverage first. It returns the newest date held, which tells you the difference between a date we do not have and a date with no racing on it. An empty array is an answer; a 403 is a plan refusal.

Yes, and you should. A settled race never changes, so store it and never re-fetch it. Courses and reference values effectively never change either. Only today's card needs re-fetching, and then only every few minutes.

From your account page, in two clicks, with no email and no phone call. Your plan runs to the end of the period you have paid for and does not renew.

If the data cannot do what you subscribed for, tell us within fourteen days and we refund it in full. You do not need to justify it beyond saying what you needed and what was missing. The refunds page is short on purpose.

No. Every jurisdiction and every field is on every paid plan. There is no per-country pricing and no premium region.

Two different things return a 429. rate_limited means too fast this minute, and Retry-After tells you how long to wait. quota_exceeded means your monthly allowance is gone and retrying achieves nothing until it resets. Branch on the code, not the status.

Subscribe to the result.received webhook. Deliveries arrive as soon as a race settles and cost nothing against your quota. A process polling every thirty seconds is about ninety thousand requests a month and still finds out later.

Usually the key field is empty or the path still has a placeholder in it. The console runs from your browser straight to the API, so a browser extension blocking the request will also do it. The output panel names which.

Yes. An identifier for a given thing never changes, so store them and use them as foreign keys. They are opaque on purpose and carry a prefix, which is why passing a horse id where a race is expected returns invalid_id rather than the wrong race.