swarmtix_event_dates_set

Replaces the dates an event runs on with the ones given, and returns the schedule as it stands afterwards. Sending the same list twice leaves the same schedule.

When you would reach for it

• Giving a new draft its schedule, usually right after swarmtix_events_create or swarmtix_events_duplicate.
• Re-dating a duplicated event for the new season.
• Adding a day to a multi-day run — send the existing dates plus the new one.

Scope

events:write

This replaces the whole schedule

It is idempotent: existing rows are reused in chronological order rather than deleted and recreated, so sending the same list twice edits the same rows and leaves the same schedule. That also preserves the row identity orders point at — changing a date's time does not orphan the tickets already sold for it.

Parameters

Each entry is either a start instant, or a start and an end separated by /:

2026-11-04T19:00:00Z
2026-11-04T19:00:00Z/2026-11-04T23:00:00Z

Written in ISO 8601, and read as UTC when no offset is given. A value carrying no offset is not interpreted in the server's local time — that would shift every date by the hosting region's offset, invisibly, until somebody in another timezone read it back.

The 50-entry cap is not a database limit. The schedule is rewritten in one pass, so a mis-parsed argument should be able to disturb an afternoon's worth of dates rather than a decade's.

Entries are sorted chronologically before anything is written, so the order you send them in does not matter.

Example call

{
  "name": "swarmtix_event_dates_set",
  "arguments": {
    "event": "spring-summit-2027",
    "dates": [
      "2027-11-03T19:00:00Z/2027-11-03T23:00:00Z",
      "2027-11-04T10:00:00Z/2027-11-04T17:00:00Z"
    ]
  }
}

What comes back

The schedule as it stands afterwards, read back from the database rather than echoed from your arguments:

{
  "eventId": "3b6f81ce-04a2-4d97-b5e8-7c10924af3d6",
  "slug": "spring-summit-2027",
  "dates": [
    {
      "id": "2c9a7f31-4d88-4f6a-b0e1-5a7c3d9e2f41",
      "start": "2027-11-03T19:00:00",
      "end": "2027-11-03T23:00:00",
      "capacity": 250
    },
    {
      "id": "5b81de04-3f6c-4a92-84d7-9e0b1a7c2f53",
      "start": "2027-11-04T10:00:00",
      "end": "2027-11-04T17:00:00",
      "capacity": 200
    }
  ]
}

capacity is whatever the reused row already carried. This tool does not set it; it is edited in the dashboard.

What happens when you call it

1. The event is resolved through the edit gate.
2. Every entry in dates is parsed. The first one that does not parse rejects the whole call, before anything is written.
3. The event's current active dates are read, in start order.
4. The call is refused if it would remove or replace a date that already has tickets sold against it, and the refusal happens here, while it is still genuinely a no-op. Both the dates you are dropping and — when the call flips the event between single-day and multi-day — every existing date are checked.
5. The schedule is written. Existing rows are reused in order; surplus rows are removed. When the call flips the event between single-day and multi-day, the writer drops every row on the losing side of that flag on its own — so no separate removal is asked for on those rows. Asking twice used to delete them once and then fail on the second attempt, leaving the event with no dates at all and the call reporting that nothing had changed.
6. The schedule is read back and compared with what you asked for, and with what was there before. If it does not match what you asked for, the call reports a partial application rather than a success — unless the schedule is identical to the one it started with, in which case it reports a plain failure that is safe to retry.
7. The final schedule is returned.

Partial application, and why it is not an error you can retry blindly

The step that writes the schedule commits in batches and does not report its own failures. So the only honest way to find out what happened is to read the database afterwards, which is exactly what step 6 does.

If some of your dates landed and the rest did not, you get this, and it is a failure result:

Swarmtix applied part of this request and then stopped. Applied: the first 2 of 4 dates. Not applied: the remaining 2. The event now has 3 date(s), where it had 2 before this call. Check the current state before trying again.

You get Swarmtix could not complete this request. Nothing was changed. instead only when the schedule that comes back is byte for byte the one that was there before the call — same rows, same times. That is checked by reading it back and comparing, not by working out which step failed: the writer commits in batches and swallows its own exceptions, so the step that threw says nothing about what survived it. When that sentence appears, a retry is safe.

Dates are compared to the second rather than to the tick, because the stored column is coarser than the value sent. Without that, every successful write would report itself as partial.

Troubleshooting

"dates is not valid: it would remove or replace a date that already has tickets sold against it. Expected a schedule that keeps every date tickets have been sold for, or those orders to be cancelled in the Swarmtix dashboard first."

Nothing was written. Either include that date in the list you send, or cancel the orders attached to it in the dashboard first.

This also fires when the call would flip the event between a single-day and a multi-day configuration, because that flip drops rows on the losing side of the change — going from two dates to one, or from one to two, puts every existing date at risk rather than just the surplus.

"dates is not valid: no dates were given. Expected between 1 and 50 dates in ISO 8601 form."

dates was empty. There is no way to clear a schedule with this tool; at least one date is required.

"dates is not valid: there were 60 of them. Expected between 1 and 50 dates in ISO 8601 form."

Split the work, or set the schedule in the dashboard.

"dates is not valid: "next friday" is not a date and time. Expected each date as "start" or "start/end" in ISO 8601 form."

Entries must be ISO 8601 instants. Nothing was written — the whole call is rejected on the first entry that does not parse, rather than writing the ones before it.

"dates is not valid: "2026-11-04T23:00:00Z/2026-11-04T19:00:00Z" ends before it starts. Expected each interval's end to be after its start."

The two halves of the interval are the wrong way round.

"dates is not valid: "2019-06-01T10:00:00Z/2019-06-01T18:00:00Z" ends more than a day in the past. Expected an end within the last day or in the future."

An end that far in the past is ignored further down and the start is written anyway, which would half-apply the call. It is refused up front instead, where the message is more useful and nothing has been written.

"dates is not valid: "2026-11-04/19:00/23:00" has more than one "/". Expected each date as "start" or "start/end" in ISO 8601 form."

One / at most per entry, separating start from end.

The times came back an hour out

Entries with no offset are read as UTC. Add an explicit offset — 2026-11-04T19:00:00+01:00 — or send the UTC instant.

"Event not found, or this connection does not have access to it."

The event does not exist, it belongs to another organisation, or this organizer may read it but not edit it.

"This connection is not authorized for events:write. Reconnect and grant it to use this tool."

Reconnect and approve events:write.

Use cases

• Scheduling a new draft straight after creating it
• Re-dating a duplicate for next season
• Adding a day — send the current schedule plus the new date
• Fixing a start time — reusing the row keeps the sold tickets attached to it