MEETIN.GS

Meetin.gs release notes

Follow verified improvements to scheduling, communication, content, and platform reliability.

August 2026: core scheduler

Booking pages and group polls now support confirmation email delivery through configured Resend credentials, calendar files, private cancellation, poll finalization, and organizer notifications.

How releases are reported

A capability appears here after the relevant user path can be tested. Early-access work stays labeled so the release record does not become roadmap marketing.

What a useful next step looks like

Bring one concrete scheduling job, the people and systems involved, and the result that should follow the meeting. Continue with current scheduler features and scope, then use Meetin.gs Help Center for the next layer of detail.

Read a Meetin.gs release claim

Which user path changed?

A release should identify the organizer or participant action, affected record, and observable result.

What evidence moved it to released?

The relevant booking, poll, email, calendar, cancellation, or failure path must be deployed and repeatable.

What remains outside the release?

Early-access dependencies, unsupported accounts, migration limits, and required configuration stay explicit.

Proof standard: Release evidence is a reproducible user result, not the existence of a design, requirement document, or unfinished integration screen.

August 11, 2026 — scheduling core and lifecycle integrity

Direct booking pages

Organizers can create a booking-mode event with dates, times, time zone, duration, location, and optional host email. An invitee can reserve an open slot with a name and valid email. Active booked slots are not offered as available to a second invitee.

Group availability polls

Organizers can publish several dates and times, collect named participant availability, review overlap, and finalize a valid winning slot. Finalization preserves the event identity and can notify participants with the confirmed details.

Email, calendar, and cancellation

When valid delivery credentials are configured, the application sends lifecycle messages to invitees, participants, and organizers. Confirmed meetings provide an iCalendar file with time-zone-aware start and end times. Private booking tokens support cancellation and release the active slot.

August 11, 2026 — safety and reliability

  • CSRF protection covers state-changing forms and produces a safe error response.
  • Public and private routes use separate analytics and caching policies.
  • Homepage query strings cannot poison the canonical cached response with a noindex state.
  • Host validation, request-size limits, security headers, and calendar-slot validation are enforced.
  • Database indexes cover event codes, response event ordering, and private response tokens.

August 11, 2026 — discovery and content quality

The sitemap includes 170 canonical English pages with preserved public slugs. Templates provide unique titles, descriptions, canonical URLs, page-specific schema, heading order, contextual links, image dimensions, and descriptive alternative text. Rendered audits check crawl reach, depth, broken links, thin content, target coverage, duplication, and family similarity.

How to interpret these notes

A release statement names a reproducible user result. Requirements documents, designs, and provider architecture do not become shipped features until the relevant organizer, participant, change, and failure paths are deployed and testable. Review current product scope before relying on an advanced capability.

Why are integrations not listed as released?

The integration directory documents intended jobs, permissions, lifecycle behavior, and acceptance criteria. A provider is not marked released until production authorization, normal booking, reschedule, cancellation, retries, failure visibility, and supported-account boundaries are verified.

Where can I report a regression?

Use the contact form with the affected URL or event code, action, expected result, actual result, time zone, approximate time, and safe reproduction steps.

Record the decision this page supports

Write the page purpose—Follow verified improvements to scheduling, communication, content, and platform reliability.—beside the concrete workflow, owner, participant, required evidence, unresolved dependency, and next review date. Use “Which user path changed?” as the first question and “What remains outside the release?” as the final outcome check.

Keep the record short enough for another person to review. Link to the relevant public page, remove sensitive data, distinguish deployed behavior from requirements, and state what would change the decision. Continue to current scheduler features and scope for the primary workflow and Meetin.gs Help Center for supporting evidence.

Completion check: Release evidence is a reproducible user result, not the existence of a design, requirement document, or unfinished integration screen.