swarmtix_events_publish

Publishes an event: it appears on the public site and its ticket types go on sale. It refuses, and changes nothing, while the event has any blocker. Nobody is emailed.

When you would reach for it

• Launching an event after swarmtix_event_readiness reports readyToPublish: true.
• Putting an event back on sale after swarmtix_events_unpublish.

Scope

events:publish

This is its own permission. events:write does not include it, so an assistant that can build a draft cannot publish it unless you also approved events:publish.

The tool is not read-only and not destructive. It is idempotent: publishing an event that is already published changes nothing, so a client may safely retry. The connection's user must be allowed to edit the event.

Parameters

Example call

{
  "name": "swarmtix_events_publish",
  "arguments": {
    "event": "spring-summit-2027"
  }
}

What comes back

{
  "eventId": "3b6f81ce-04a2-4d97-b5e8-7c10924af3d6",
  "slug": "spring-summit-2027",
  "status": "Published",
  "changed": true,
  "warnings": [
    { "code": "NoTimezone", "message": "The event has no timezone, so its dates and sale windows are read as UTC. Set one with swarmtix_events_update before setting dates." }
  ]
}

What happens when you call it

1. The event is resolved through the edit gate.
2. The event is checked with the same rules as swarmtix_event_readiness. The rules are shared, not copied.
3. If the event is already published, the call ends here with changed: false.
4. If there is any blocker, the call is refused and nothing is changed. The refusal lists every blocker, so you can fix them in one pass.
5. Otherwise one column is written: the event's status becomes Published. This is what the dashboard's publish button does.
6. The status is read back and returned.

Troubleshooting

"This event cannot be published yet. Nothing was changed. Fix these first: ..."

The event has one or more blockers. Each line gives the blocker and the tool or dashboard page that fixes it. Fix them all, then call again. swarmtix_event_readiness shows the same list without trying to publish.

"The event's status changed while this call ran. Nothing was changed. Read it again with swarmtix_event_readiness and retry."

Somebody changed the event's status between the check and the write, for example in the dashboard. Nothing was written. Read the event again and retry.

"The status was written, but a different status was read back right after, so another change landed at the same time. Read the event again to see its current status."

The write happened, but another change landed at the same moment, so the status you see is not the one this call wrote. Read the event again to see where it is now.

"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:publish."

The connection was authorized before the permission existed or without it. Reconnect and approve events:publish.

Good to know

• The dashboard's header can show the old status. The dashboard keeps the selected event in a cookie. It shows the old status until the event is selected again.
• Readiness is slightly stricter than the dashboard in one place. Only active ticket types count, and an inactive payment account blocks a paid event. In one case it is more lenient: an inactive paid ticket with no payment account.
• There is a very small gap between the check and the write. The write refuses when the status changed since it was read, which narrows the gap but does not close it. The dashboard has the same gap.
• Plan limits are not checked here. The dashboard does not check them at publish either. An online event on the free plan, and an archived event, are readiness blockers.

Use cases

• Launching an event once a draft is complete
• Re-opening sales after a pause