Your facts, your dates,
maintained by you

Send multipart/form-data with a document that shows you are who you say you are — a company registration, a letterhead, a domain-ownership screenshot, anything a person can check.

# One request. The slug is the last part of your page's URL.
curl -X POST https://supercars.tours/api/v1/claim-my-business \
  -F "slug=alpine-drives" \
  -F "name=A. Director" \
  -F "email=ops@example.com" \
  -F "role=Operations" \
  -F "message=Company registration attached." \
  -F "proof=@registration.pdf"

202 Accepted means it is queued for a human, not that it is approved:

{
  "claim": 41,
  "operator": "alpine-drives",
  "status": "new",
  "note": "A person reviews every claim. If it checks out you will receive an API key by email; nothing on your page changes until then."
}

Notes worth reading before you send

• Your document is not public. It is stored under a private prefix that our public media route refuses to serve. It cannot be reached by guessing a URL.
• We identify the file by its contents, not its name or the type your client declares. Renaming a .exe to .pdf is rejected. SVG is refused outright — it can carry script.
• Both halves of the validation come back together. If the form and the file are both wrong, one 422 tells you about both, so you are not fixing one problem per round trip.
• Five claims an hour per address. Enough for a typo or two, not for scanning.

Send JSON containing only the fields you want to change. It is a PATCH rather than a PUT on purpose:

• Leave a field out and it is untouched.
• Send null and it is cleared.

Those two are different, so there is no way to wipe a value by forgetting to mention it.

curl -X PATCH https://supercars.tours/api/v1/update-my-details \
  -H "Authorization: Bearer $SCT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "car_policy": "both",
        "length_min_days": 3,
        "length_max_days": 7,
        "price_band": "8-15k",
        "hotel_level": 5,
        "convoy_size": null
      }'

{
  "operator": "alpine-drives",
  "updated": ["car_policy", "length_min_days", "length_max_days", "price_band", "hotel_level", "convoy_size"],
  "note": "Recorded, and logged against your page as operator-supplied. Editorial text and the toured label are unchanged."
}

The updated array is what actually changed. Compare it with what you sent if you want to be certain.

Things that will be refused

• An empty body. {} is a 422, not a success. A client sending nothing has a bug, and "200, nothing changed" would hide it.
• An unknown field. Named in the error rather than silently dropped, so a typo does not look like it worked.
• A backwards range. length_min_days above length_max_days is two individually valid numbers that are jointly wrong.
• A non-http URL. javascript: and data: are rejected, because website is rendered as a link.

Returns the next tour we hold for you, including one still waiting for moderation. A read that only showed published rows would answer "nothing" to an operator whose submission is sitting in the queue, which is the least useful true answer available.

curl -H "Authorization: Bearer $SCT_KEY" \
  https://supercars.tours/api/v1/my-next-tour

{
  "operator": "alpine-drives",
  "next_tour": {
    "title": "Stelvio & Gavia, four days",
    "start_date": "2026-09-14",
    "end_date": "2026-09-17",
    "destination": "alps-dolomites",
    "url": "https://example.com/tours/stelvio-2026",
    "price_from": 6400,
    "currency": "EUR",
    "external_ref": "stelvio-2026-09",
    "status": "pending"
  },
  "note": "Held as \"pending\" — a person reviews every date before it appears."
}

With nothing on file, next_tour is null and the note says so. Finished and archived tours are never returned — "next" means next.

status is pending while it waits and published once it is live on your page. Poll this if you want to know when it went up; a few times a day is plenty.

One tour per request. Send the whole thing; this replaces rather than patches.

curl -X PUT https://supercars.tours/api/v1/my-next-tour \
  -H "Authorization: Bearer $SCT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "title": "Stelvio & Gavia, four days",
        "start_date": "2026-09-14",
        "end_date": "2026-09-17",
        "destination": "alps-dolomites",
        "url": "https://example.com/tours/stelvio-2026",
        "price_from": 6400,
        "currency": "EUR",
        "external_ref": "stelvio-2026-09"
      }'

{
  "operator": "alpine-drives",
  "inserted": 1,
  "updated": 0,
  "status": "pending",
  "note": "Received. A person reviews every date before it appears on your page."
}

Everything lands as pending. Nothing you send can publish itself. A person reads every date before it appears, usually within a day or two. If a date is wrong after it is published, just send it again with the same external_ref.

Sending an unrecognised destination returns 422 with the offending value named, rather than a server error. Leave it out if none of the nine fits.

The same rules as PUT /my-next-tour, but up to 200 tours in one request. Use this if your season is already in a system that can post to us; use PUT if you are updating one date by hand.

curl -X POST https://supercars.tours/api/v1/tour-dates \
  -H "Authorization: Bearer $SCT_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "tours": [
        { "title": "Spring Alps", "start_date": "2026-04-10", "end_date": "2026-04-14",
          "destination": "alps-dolomites", "external_ref": "alps-2026-04" },
        { "title": "Dolomites Summer", "start_date": "2026-07-02", "end_date": "2026-07-06",
          "destination": "alps-dolomites", "external_ref": "dolo-2026-07" }
      ] }'

It is one transaction and one validation pass: if any tour in the batch is invalid, none of them is saved and the errors are indexed so you know which. An external_ref must be unique within a single request as well as across requests.

{
  "error": "Nothing was saved.",
  "errors": [
    { "index": 1, "field": "end_date", "message": "The end date cannot be before the start date." }
  ]
}

Because every ref is an upsert, re-posting your full calendar is safe and is the simplest way to keep us in step. Nightly is fine; the limit is 60 an hour.