swarmtix_ticket_types_update

Changes one of an event's ticket types and returns it as it stands afterwards. Only the fields you give are changed; the rest keep the values they already have.

When you would reach for it

• Fixing a typo in a ticket name or description.
• Raising or lowering a price before anything has sold.
• Releasing more stock — raising the quantity on a tier that is selling well.
• Adjusting per-order limits when a group booking hits the ceiling.

Scope

events:write

It is idempotent: sending the same arguments twice leaves the same ticket type, so a client may safely retry.

Once tickets have sold, the price is locked

This ticket type cannot be changed because tickets of it have already been sold. Its price and whether it is free can only be changed while nothing has been bought. Nothing was changed.

To reprice a tier that is already selling, create a new ticket type at the new price with swarmtix_ticket_types_create and deactivate the old one in the dashboard. That is also better for your buyers: it leaves the price they paid on the record they bought from.

Everything else — name, description, quantity, per-order limits — can still be changed after tickets have sold, provided the call does not also carry a price.

Parameters

Every omitted field is filled in from the stored row before the change is applied, so omitting one genuinely keeps it rather than blanking it.

Omitting price also keeps the ticket's paid-or-free kind as stored rather than re-deriving it.

Which fields this tool owns, and which it preserves

The update behind this tool rewrites every field it knows about from the model it is handed, whether or not you named it. So the list of fields this tool sets is the real contract, and it is worth having in writing.

Owned — this tool sets these, from your argument or from the stored value when you omit it:

Preserved — this tool has no argument for these and copies each one from the stored row, unchanged:

Untouched — the update never writes these at all: the ticket type's id, its event, its display order, how many are still available, and whether it is active. That matters on a type that has sold: re-deriving would count as a change of kind, and an edit to the description alone would then be refused for a reason you could not act on.

Changing quantity does not change available

Example call

{
  "name": "swarmtix_ticket_types_update",
  "arguments": {
    "event": "spring-summit-2027",
    "ticketType": "b7d3e5a1-92c4-4f18-8a6b-3e0f1c7d9a52",
    "description": "All talks, the workshops and the evening reception.",
    "maximumPerOrder": 6
  }
}

What comes back

The ticket type as stored afterwards — the same shape swarmtix_ticket_types_create returns:

{
  "id": "b7d3e5a1-92c4-4f18-8a6b-3e0f1c7d9a52",
  "eventId": "3b6f81ce-04a2-4d97-b5e8-7c10924af3d6",
  "name": "Early Bird",
  "description": "All talks, the workshops and the evening reception.",
  "price": 39.5,
  "free": false,
  "quantity": 100,
  "available": 62,
  "minimumPerOrder": 1,
  "maximumPerOrder": 6,
  "onSaleFrom": "2027-01-14T11:02:48",
  "onSaleUntil": "2027-11-03T19:00:00",
  "active": true
}

It is read back from the database rather than echoed from your arguments, so what you see is what was stored.

What happens when you call it

1. The event is resolved through the edit gate.
2. ticketType is checked against this event. That pairing is load-bearing: the update itself finds the row by id alone, with no event filter, so a ticket type id belonging to another organisation's event would otherwise be edited quite happily.
3. Omitted fields are filled in from the stored row, and so is every field this tool takes no argument for — see the field list.
4. Everything is validated — the same rules as on create.
5. The change is applied. A price or kind change on a type that has sold is refused here, and nothing else in the call is applied.
6. The stored row is read back and returned.

Troubleshooting

"This ticket type cannot be changed because tickets of it have already been sold. Its price and whether it is free can only be changed while nothing has been bought. Nothing was changed."

See above. Drop price from the call to change the other fields, or add a new ticket type at the new price.

"ticketType is not valid: there is no ticket type with that id on this event. Expected the id of a ticket type on this event."

The id does not name an active ticket type on the event you gave. Three likely causes: a typo, a ticket type that belongs to a different event, or one that has been deactivated. List them with swarmtix_ticket_types_list.

"ticketType is not valid: "early-bird" is not an id. Expected the id of a ticket type on this event."

Ticket types have no slug. Use the id.

"ticketType is not valid: it was empty. Expected the id of a ticket type on this event."

The argument was missing or blank.

"price is not valid: it was -5. Expected an amount from 0 to 1000000."

Prices cannot be negative.

"maximumPerOrder is not valid: it was 250. Expected a whole number from 1 to 100."

The per-order maximum cannot exceed the quantity on sale.

The ticket is still sold out after raising quantity

Expected — see availability. The two numbers are separate.

"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

• Copy fixes on a live event, safely, without touching the price
• Pre-sale repricing while nothing has been bought
• Group bookings — raising maximumPerOrder for one tier
• Tidying a duplicated event's tiers before publishing it