Alle Änderungen, neue Endpoints und Breaking Changes — chronologisch dokumentiert.
Das Feld users am Typ Mandant wurde entfernt, da es aufgrund eines internen Fehlers keine Daten lieferte. Die Nutzer eines Mandanten liefert usersOfMandant.
Mandant.users — Ersatz ist usersOfMandant bookingEligibility sagt jetzt genauer, ob und warum ein Termin oder Block buchbar ist. Bestehende Aufrufe bekommen dadurch teils andere Antworten — ein voller Termin etwa FULLY_BOOKED statt BOOKABLE.
BookingEligibilityStatus: FULLY_BOOKED (auch die Warteliste ist voll), NOT_ENOUGH_CREDITS, ONLY_BOOKABLE_AS_BLOCK, CANCELLED, ALREADY_STARTED und ONLY_BOOKABLE_AS_SINGLE_EVENTS (Block nach der Freigabe) WAITLIST oder FULLY_BOOKED, abgesagte CANCELLED, begonnene ALREADY_STARTED — bisher jeweils BOOKABLE NOT_ENOUGH_CREDITS statt BOOKABLE ONLY_BOOKABLE_AS_BLOCK statt NOT_YET_OPEN DEADLINE_PASSED steht nur noch für den Anmeldeschluss aus dem Buchungsprofil NOT_AUTHENTICATED Mehrere Termine eines Kurses lassen sich zu einem Block zusammenfassen, den Teilnehmer als Ganzes buchen. Die Funktion wird je Mandant freigeschaltet.
eventBlock: EventBlockInput bei addEventsV2 und createCourse — ist es gesetzt, entstehen die Termine als Block. Höchstens 20 Termine eventBlockId: ID bei AddEventsV2Result getEventBlock(eventBlockId: ID!): EventBlock getEventBlocks(mandantIds: [ID!], offset: Int, limit: Int, fromDate: Date, toDate: Date): EventBlocksResult! — Blöcke, die den Zeitraum überschneiden, sortiert nach dem ersten Termin, höchstens 50 je Seite updateEventBlock(eventBlockId: ID!, eventBlock: EventBlockInput!, events: EventBlockEventsInput): EventBlock! — ersetzt die Block-Einstellungen, optional auch die gemeinsamen Termin-Einstellungen releaseEventBlock(eventBlockId: ID!): Boolean! — gibt die Restplätze einzeln frei und beendet den Blockverkauf; automatisch über autoReleaseDaysBefore extendEventBlock(sourceEventId: ID!, dates: [CopyEventDateInput!]!, numPlaces: Int, credits: Int, suppressNotifications: Boolean): [Event!]! — trägt Termine nach; bestehende Blockbucher bekommen sie ohne Aufpreis EventBlock, EventBlocksResult, EventBlockInput und EventBlockEventsInput eventBlock: EventBlock beim Typ Event Mandant: eventBlocksEnabled: Boolean (darf Blöcke anlegen) und hasEventBlocks: Boolean! (hat mindestens einen Block) copyEvent legt bei einem Block-Termin einen Einzeltermin außerhalb des Blocks an Teilnehmer buchen einen Block mit einem Aufruf: Alle künftigen Termine werden auf einmal gebucht, der Blockpreis wird einmal bezahlt — mit Punkten, online oder direkt beim Anbieter. Mitglieder einer Block-Flatrate buchen kostenlos.
createEventBlockBooking(eventBlockId: ID!, paymentMethod: EventBlockPaymentMethod): CreateEventBlockBookingResult! — bei Onlinezahlung mit paymentUrl und invoiceId im Ergebnis createEventBlockBookingForUser(userId: ID!, eventBlockId: ID!, paymentMethod: EventBlockPaymentMethod, skipInvoice: Boolean, suppressNotifications: Boolean): CreateEventBlockBookingResult! — der Anbieter bucht für einen Teilnehmer deleteEventBlockBooking(eventBlockId: ID!): String! — Storno durch den Teilnehmer bis zum ersten Termin, mit Erstattung des Blockpreises in Punkten. Eine mit Geld bezahlte Blockbuchung storniert nur der Anbieter deleteEventBlockBookingForUser(userId: ID!, eventBlockId: ID!, refundCredits: Boolean): String! — der Anbieter nimmt einen Teilnehmer heraus, mit oder ohne Erstattung des Blockpreises availablePaymentMethodsForEventBlock(eventBlockId: ID!): [MolliePaymentMethod!]! EventBlock: angebotene Zahlungsarten paymentMethods (leere Liste = kostenlos), Blockpreis in Punkten credits oder Geldpreis, Block-Flatrate über flatrateUsergroups, dazu bookingEligibility und myEventBlockBooking für den Betrachter EventBlockBooking, EventBlockPurchase (Kaufbeleg), EventBlockRefund und CreateEventBlockBookingResult PaymentMethod (free, credits, money, manual), EventBlockPaymentMethod (credits, money, manual), EventBlockBookingStatus und EventBlockBookingEndedBy eventBlockBooking: EventBlockBooking beim Typ Booking Anbieter sagen ganze Blöcke ab, lassen einzelne Block-Termine ausfallen oder verschieben sie auf einen Ersatztermin. Dazu kommen eine Anwesenheitsübersicht je Block, ein neuer Nachrichtentyp und Block-Einträge im Protokoll.
cancelEventBlock(eventBlockId: ID!, futureEvents: EventBlockFutureEvents!, refundCredits: Boolean, hint: String, suppressAllNotifications: Boolean, suppressTrainerNotification: Boolean): Boolean! — sagt einen ganzen Block ab, wahlweise mit Erstattung des Blockpreises EventBlockFutureEvents: cancel (künftige Termine fallen mit aus) oder continueAsSingleEvents (sie laufen als Einzeltermine weiter) refundEventBlockEvent(eventId: ID!): Boolean! — ein Block-Termin fällt aus, Einzelbucher bekommen ihren Terminpreis zurück createReplacementEvent(eventId: ID!, date: CopyEventDateInput!, numPlaces: Int): Event! — ein Block-Termin fällt aus und bekommt einen Ersatztermin, alle Buchungen wandern mit. Block-Termine fallen nur über diese beiden Wege aus, nicht über cancelEventV2 replacedByEvent: Event und replacementFor: Event beim Typ Event attendanceOverview: EventBlockAttendanceOverview am EventBlock — Auslastung und Anwesenheit je Termin und Teilnehmer, nur für Anbieter und Trainer des Blocks eventBlockCancelled im Enum MessageType eventBlock und eventBlockBooking beim Typ Log, neuer Filter eventBlockId in LogsSearchParams LogType: zehn von eventBlockCreated bis eventBlockEventRefunded, dazu creditsAddedEventBlockBooking und creditsRemovedEventBlockBooking Buchungsprofile haben jetzt einen Typ: event für Termine, block für Blöcke. Aufrufe ohne Typ verhalten sich wie bisher und sehen nur Termin-Profile.
BookingProfileType mit event und block type: BookingProfileType! beim Typ BookingProfile type bei bookingProfilesOfMandant — ohne Angabe vorerst nur Termin-Profile. Geplant ist, dass ohne type künftig alle Profile kommen; Clients sollten type deshalb schon jetzt mitgeben type bei createBookingProfile (Standard: event) und updateBookingProfile (ohne Angabe bleibt der Typ) bookingProfileEventTemplateCount(bookingProfileId: ID!): Int! — wie viele Terminvorlagen ihr Profil verlieren, wenn es gelöscht wird Ein Mandant kann nur noch etwas gegen Onlinezahlung anbieten und verkaufen, wenn er zahlungsbereit ist: mit Mollie verbunden und mit mindestens einem aktiven Zahlungsmittel in seiner Währung. Ob das zutrifft, liefert MandantBilling.canReceivePayments.
mandant-cant-receive-payments: Speichern mit Onlinezahlung (Termin mit canBePurchased, Block mit money, createProduct, updateProduct, setProductActive) und Kaufen mit Onlinezahlung (createBookingV2, createMultiBookingV2, Blockbuchung, buyShoppingCart) skipInvoice Ob ein Mandant Onlinezahlungen annehmen kann, steht jetzt am MandantBilling. Das Feld am Mandant ist abgekündigt und liefert bis zur Entfernung denselben Wert.
MandantBilling.canReceivePayments: Boolean! über getMandantBilling — ersetzt Mandant.canReceivePayments Mandant.canReceivePayments liefert bei verbundenen Mandanten ohne aktives Zahlungsmittel jetzt false statt true Käufer können einen Shop-Kauf innerhalb der Widerrufsfrist widerrufen. Terminkäufe sind gesetzlich vom Widerrufsrecht ausgenommen und erscheinen nicht in der Liste.
getMyRevocablePurchases: [RevocablePurchase!]! — Käufe mit laufender Frist, inklusive revocationDeadline declareRevocation(invoiceId: ID!): Revocation! RevocablePurchase und Revocation Neue Felder rund um Buchung, Rechnung und Zahlung. Alle Änderungen sind additiv.
availablePaymentMethodsForEvent(eventId: ID!): [MolliePaymentMethod!]! invoiceId: ID und invoiceStatus: InvoiceStatus bei Booking — nur für den Buchenden selbst und Event-Admins, sonst null invoiceId: ID bei CreateBookingV2Result myBooking: Booking bei Event — liefert die eigene Buchung unabhängig von der Einstellung publicParticipantNames molliePaymentStatus und molliePaymentMethod bei Invoice, beide null solange keine Online-Zahlung existiert Wir informieren dich bei neuen Features, Breaking Changes und Deprecations.