These terms apply whenever anyone connects to AnyRun's API, the data access, using a token minted by your organisation: you, a staff member, a timing partner, or an AI agent acting on your instructions. They sit under the Terms of Use, including its Australian Consumer Law and liability sections, and alongside the Privacy Policy. If you run events, the Organiser Agreement applies too.

Who is bound: the organisation the token belongs to. Every token acts for the organiser that minted it, whoever happens to be holding it, which is why the custody section below matters more than any other clause on this page.

The Platform has exactly one inbound API: a single MCP endpoint at POST /mcp: the protocol AI tools such as Claude and ChatGPT speak natively. It exposes three tools, and only three:

• describe_schema returns the CSV import contracts plus your organisation's name, its event and distance names, dates and ids, and the scopes your token carries. Structure only: entrant, volunteer and result rows stay out of it.
• validate_import parses a CSV, format-checks every cell, and stages the result as a dry-run diff. Nothing is written to your event; the batch waits in staging (more on that below).
• confirm_import applies a staged batch. The only call that writes.

There are no tools that read data back out. No entrant list, no search, no export. That is a property of the architecture: the tools do not exist, so there is no setting to flip. The practical consequence, and the reason we designed it this way, is that the worst a leaked token can do is read event names and import formats and propose rows for your approval. We commit to keeping the API write-only; if that ever changes, these terms change first, with notice, before any new capability ships.

An API token is minted in your console by an owner or admin. The facts that matter:

• Shown once. The token (prefixed ros_) appears in full exactly once, at mint. At rest we keep its SHA-256 hash and its first ten characters (the short prefix that identifies it in your console token list) and we could not re-display the full token if we wanted to. Lose it? Revoke it and mint another.
• Scoped. Reading the import contracts and your event structure is on for every token; each import kind (entries, timing, volunteers) is a separate scope you tick at mint. A timing-only token cannot touch entries, and no scope you can grant reads entrant data.
• Bounded. Up to 10 tokens per organisation (revoking one frees its slot) each with an optional expiry date. One token per partner, per job, retired when the job is done.
• Revocable instantly. Revocation is checked on every call, so it takes effect mid-session, before any next sign-in.
• Audited. Every mint, staged import, confirmed import and revocation lands in your organisation's append-only audit log.

Treat a token like a password. Store it in a secrets manager; share it only with the person or tool doing the job; and revoke it the moment the job ends or you suspect it has leaked. If you believe a token has been exposed, revoke it first and then tell us at support@anyrun.net so we can check the audit trail with you.

Your organisation owns what its tokens do. Anything done with a live token counts as done by your organisation, until the moment you revoke it. The API's design keeps the stakes low: every import must still be confirmed, nothing can be read back out, and revocation is instant. We are not responsible for imports made with a token your organisation failed to keep secret, except to the extent the failure was ours.

Every import happens in two steps, and only the second writes. Validation returns a staged import: a verdict for every row (returned as counts by outcome, plus up to twenty-five flagged samples with machine reason codes), the header mapping echoed back, and the batch's row count against its printed cap: 2,000 entry, 5,000 timing or 500 volunteer rows per batch. The batch holds for 60 minutes; left unconfirmed, it expires untouched and nothing was written.

Confirming is deliberate and idempotent: confirm the same batch twice and it lands once. Entries land registered; volunteer rosters arrive confirmed or waitlisted; chip times go into your event's timing data, and the API does not publish results. Whether an event's results are public is a console decision a human makes, and the API cannot flip it in either direction. If you have already published them, a correction batch confirmed through the API lands live. Why two steps: an agent can prepare the work, but a person owns the decision. These terms require exactly what the tools already enforce; review the diff before you confirm it.

Rows pushed through the API usually contain personal information: entrants' names and emails, volunteers' details. You confirm your organisation has the right to give us that data: it is your entrants' and your volunteers' information, collected by you, lawfully. Once through the API it is handled exactly as the Privacy Policy describes.

Staged data doesn't linger, and here is the shape of the purge. A batch's submitted rows are cleared from the staging record no earlier than seven days after it is confirmed, cancelled or expires. The purge runs as part of your organisation's routine API activity, so the final batch of an organisation that stops using the API can hold its rows for longer than that. What stays for the audit trail is the dry-run report: the verdict counts, the header mapping you confirmed, and up to twenty-five flagged sample cells, which, for an entries batch, can include an entrant's email address. The full row payload is what goes.

The API is open by default (no application form, no approval queue). You agree not to:

• Scrape or harvest. Don't use the API, your token, or the Platform's public pages for bulk collection of data: the API imports; it is not a collection tool, and the Platform's anti-scraping limits apply to everyone.
• Probe or subvert. No vulnerability scanning, no attempts to bypass authentication, rate limits or the injection fences that mark spreadsheet content as untrusted data. Found a genuine security issue? We want to hear about it. The Security page explains how to report it.
• Resell or share access. Tokens are for your organisation's own events. Hand one to a timing partner or an agent working for you. Passing it to a third party as a product, a service or a favour is a breach of these terms.
• Import data you have no right to. Someone else's mailing list is not an entry list. The previous section is a promise; this is the rule behind it.

The hard numbers: a ceiling of 30 staged imports per hour per token, 1 MB per request, and the per-batch row caps above. Beneath them sits a per-token rate budget at the edge that we tune quietly to absorb bursts and keep the API responsive. Hit any limit and you get a clear answer: a 429 with a retry time, or a refusal naming the limit.

Limits may change as the Platform grows. We tune them to keep the API responsive for every organisation. Where a changed limit could break a working integration we treat it as a breaking change and give notice (next-but-one section); we act immediately only where abuse or the Platform's stability requires it.

The API ships as part of the Platform at no extra charge, and at this tier it is best-effort: there is no SLA. We build for reliability and the API is stateless by design, but we do not promise uptime, and maintenance or outages may interrupt it. Design for that: idempotency keys make every retry safe: a replayed validation returns the same batch, and a replayed confirm lands nothing twice. If we ever offer a paid tier with an availability commitment, that will be its own agreement. Nothing in this section excludes a guarantee the Australian Consumer Law gives you.

We may suspend or revoke a token (or your organisation's access to the API) if it is used in breach of these terms, abusively, or in a way that creates a security or legal risk. We act proportionately: a single misbehaving token is revoked, leaving the rest of the organisation's access in place; where practical we tell you before or promptly after; and access comes back when the issue is resolved. Same doctrine as the Terms of Use: suspension is a safety valve, and it leaves your data and your ability to export it untouched.

Additive changes ship without ceremony: a new optional column, a better error message, a new tool your token can ignore. Breaking changes get reasonable notice (we aim for at least 30 days) so a timing partner mid-season isn't stranded by a contract that shifted under them. describe_schema returns the current contract on every call, so an agent can re-check the shape before every import.

When these terms change materially we bump the version and effective date at the top of this page. Continued use of the API after a change means you accept it; and if you don't, revoke your tokens and stop using the API; because it carries no separate charge, walking away costs nothing.

The Australian Consumer Law, liability and indemnity provisions of the Terms of Use apply to the data access exactly as they apply to the rest of the Platform. In short, and subject to every non-excludable right: neither party is liable to the other for indirect or consequential loss; each party's total liability is capped at the platform fees paid to AnyRun in the twelve months before the claim, mutually, in both directions; and the cap does not apply to fraud, to a party's own reckless or wilful misconduct, or to liability that cannot be limited at law. Any indemnity you owe us covers only claims caused by your own conduct, and it stops where the loss comes from our negligence or breach. And because this tier carries no SLA, there are no service credits.

These terms are governed by the laws of South Australia, Australia, and the courts of that state have jurisdiction, without limiting any non-excludable right you have to bring a matter elsewhere. Questions about the API, a token, or an integration you're planning: support@anyrun.net.