Groups.io: Changelog

Subscribe via RSS

Area All areas Messages & Topics Editor & Drafts Hashtags Email & Delivery Members Moderation Group Settings Subgroups Integrations Calendar Files Photos Wiki Databases Chat Ask Subscription Account & Login Billing Enterprise Design & Accessibility Public Pages & Help Mobile App Site-wide

Type All types New Change Bug fix API

Search

Filter Clear

---

September 11, 2026

Calendar

• BUGFIX: RSVP comments in the event Responses page's gallery view were clipped to a single line. Comments now wrap so the full text is readable, including on phones. https://beta.groups.io/g/main/message/40904

September 4, 2026

Calendar

• API NEW: Creating a calendar event through the API never notified the group: the web's "Add Event & Invite Group" button had no API equivalent, and the send_notice parameter - despite its name - only controls the notice sent when the event starts. The event endpoints now accept a send_invite parameter (/addevent, /updateevent, /addrepeatevent, /updaterepeatevent, /splitrepeatevent) that posts the #cal-invite message with its ICS attachment to the group, and /deleteevent and /deleterepeatevent accept send_cancel to post the #cal-cancelled notice. The send_notice parameter documentation has been rewritten to make clear what it actually does. https://beta.groups.io/g/api/message/464

August 29, 2026

Calendar

• API BUGFIX: The documentation for /addrepeatevent and /updaterepeatevent listed the wrong values for several repeat parameters. repeat_type was described as 1=daily, 2=weekly, 3=monthly, 4=yearly, when 2 actually means every Monday/Wednesday/Friday and weekly on selected days is 4, so a client following the documentation to create a weekly event silently got a Monday/Wednesday/Friday series instead. The repeat_ends values for "times" and "date" were also reversed, and the month_type values were wrong and incomplete. The documentation now matches the implementation, and both endpoints reject an out of range repeat_type with bad_request: invalid repeat_type instead of quietly creating a different repeat pattern. An unparseable timezone, which shifted every occurrence to the wrong day of the week, is now rejected the same way.
• API BUGFIX: /updaterepeatevent, /splitrepeatevent and /deleterepeatevent still acted on repeating events that had already been deleted; updating or splitting one brought the series back and started generating its occurrences again. They now return bad_request for a deleted series.
• BUGFIX: A deleted repeating event could come back on its own. If the series had been created from an emailed calendar invitation, a later invitation carrying the same event id — a re-send, or an update from the organizer's calendar program — recreated it as a new live series, and an RSVP reply to a reminder email sent before the deletion could do the same. Deleting a repeating event now sticks: invitations and RSVP replies for a deleted series are ignored.
• NEW: Calendar events that request RSVPs and have a maximum attendee limit now display a badge on the calendar showing the number of spots still available, or Full when the event has reached its limit — so you can scan a month of events for one with space without opening each event. The badge appears in the month, week, day, and list views of both a group's calendar and the consolidated calendar, and hovering over it shows the details. Events without an attendance limit are unchanged. beta.groups.io https://beta.groups.io/g/main/message/40912
• BUGFIX: When a member accepted or declined a calendar invitation from a group hosted on its own domain — an Enterprise group, or a group with its own subdomain — the reply their calendar program sent back automatically (Outlook's "Accepted: ..." message, for example) was rejected by our mail server, so the member received a confusing "This group does not exist" bounce and their response was never recorded on the event's RSVP list. Those replies are now processed just as they are for groups at groups.io addresses: the response is recorded and no bounce is sent.