Reihenfolge beim Anlegen

Fast alles bei Memberfy hängt von etwas ab, das vorher angelegt wurde: Die Lektion braucht das Modul, das Modul den Kurs, der Kurs den Bereich. Ruft man die API in der falschen Reihenfolge auf, geht nichts kaputt, aber jeder vorgezogene Aufruf wird abgelehnt. Dieser Leitfaden zeigt die richtige Reihenfolge und die ID, die von einem Aufruf an den nächsten weitergegeben wird.

#Die Abhängigkeitskarte

Anders gelesen:

Bei allen Aufrufen unten gehören Authorization und X-CommunityId dazu. Siehe Authentifizierung und X-CommunityId.

#Kurs

1. Abschnitt (falls noch keiner existiert): POST /api/sections mit title und visibility. Speichere data.id als sectionId.
2. Kursbereich: POST /api/spaces mit sectionId, title und module: "courses". Speichere die spaceId.
3. Kurs: POST /api/courses mit communityId (dieselbe wie im Header), spaceId, title, slug und level (beginner, intermediate, advanced). Er entsteht als Entwurf. Speichere die courseId.
4. Module: POST /api/courses/module mit courseId und title, eines pro Modul. Speichere jede moduleId.
5. Lektionen: POST /api/courses/lesson mit moduleId, title und type (text, image, video, link).
6. Veröffentlichen: PUT /api/courses/{id} mit status: "published". Nur ein veröffentlichter Kurs nimmt Einschreibungen an.

Für spätere Anpassungen: PUT und DELETE /api/courses/module/{moduleId} benennen ein Modul um, ändern seine Reihenfolge und löschen es (samt Lektionen); PUT und DELETE /api/courses/lesson/{lessonId} ändern Titel, Typ, Dauer und Reihenfolge einer Lektion, verschieben sie in ein anderes Modul desselben Kurses (moduleId) und löschen sie. Beim Löschen bleibt der Fortschritt aller erhalten, die sie schon angesehen haben.

Um den Kurs zu verkaufen, mach weiter mit einem Produkt, das den Bereich freigibt (siehe Veranstaltung, Schritte 3 und 4, die genauso gelten).

#Mentoring

Eine Gruppe mit eigener Pinnwand, Treffen und monatlicher Abrechnung. (Mit der Vertragslaufzeit bekommt die Option aus Schritt 3 zusätzlich commitmentMonths.)

1. Privater Bereich der Gruppe: POST /api/spaces mit module: "feed" und visibility: "private". Speichere die spaceId.
2. Treffen: POST /api/events, eines pro Treffen, mit spaceId, title, slug, type: "online", startTime und endTime.
3. Abrechnungsoption: POST /api/products mit type: "SUBSCRIPTION", title, price, billingInterval: "MONTHLY" und allowedPaymentMethods. Speichere die id des Produkts.
4. Plan: POST /api/subscription-groups mit name und productIds: [<ID aus Schritt 3>]. Speichere die id des Plans.
5. Den Bereich für den Plan freigeben: PUT /api/spaces/{id} mit access: { "subscriptionGroupIds": [<ID des Plans>] }.

Schritt 5 funktioniert erst nach Schritt 4: Der Plan muss existieren, damit er im Zugriff genannt werden kann.

#Veranstaltung

Eine Präsenzveranstaltung mit bezahltem Ticket und Hinweis im Feed.

1. Veranstaltungsbereich: POST /api/spaces mit module: "events".
2. Veranstaltung: POST /api/events mit spaceId, title, slug, type: "in_person", startTime, endTime und der Adresse (street, number, city …).
3. Ticket: POST /api/products mit type: "ONE_TIME", price, hasStock: true und stockQuantity. Danach veröffentlichen.
4. Den Bereich für Käufer freigeben: PUT /api/spaces/{id} mit visibility: "private" und access: { "productIds": [<ID des Tickets>] }.
5. Angehefteter Hinweis: POST /api/content im Feed-Bereich und PUT /api/feed/{type}/{id}/pin mit der ID des Beitrags.

#Plan mit Zusatzprodukten

1. Abrechnungsoptionen des Plans: ein POST .../products pro Option (Monatlich, Jährlich), type: "SUBSCRIPTION".
2. Das Zusatzprodukt: ein weiteres POST .../products, type: "SUBSCRIPTION", billingInterval: "MONTHLY". Es kommt in keine productIds eines Plans.
3. Plan: POST .../subscription-groups mit den productIds aus Schritt 1.
4. Zusatzprodukte im Plan: PUT .../subscription-groups/{id} mit addOnProductIds: [<ID aus Schritt 2>].

#Vor dem Verkaufen: das Auszahlungskonto

Eine Reihenfolge, die für jeden Verkauf gilt:

1. POST .../business-information und .../submit.
2. POST .../payout-settings und .../submit.
3. Auf beide Genehmigungen warten (bis zu 7 Werktage). GET .../payout-settings/prerequisites sagt, was noch fehlt.

Produkte, Optionen, Pläne, Add-ons, Gutscheine und Downsell-Angebote kannst du schon vor der Genehmigung anlegen und bearbeiten: Das Produkt entsteht als DRAFT, in der Währung des Landes aus den Geschäftsinformationen (in jedem Status) oder ohne sie in BRL. Das Veröffentlichen (POST .../products/{id}/publish oder PUT .../products/{id} mit status: ACTIVE), der Checkout und die Auszahlung warten auf die Genehmigung. Werden genehmigte Geschäftsinformationen bearbeitet, gehen sie zurück auf PENDING und brauchen erneut .../submit; bis zur neuen Genehmigung lehnt der Checkout ab.

#Die Fehler, wenn ein Schritt fehlt

Einige Formatvalidierungen antworten noch auf Englisch (etwa Valid course ID is required, wenn die ID keine UUID ist).

#Tipps

• Speichere jede ID, die in data.id zurückkommt: Genau die verlangt der nächste Aufruf.
• Schick dieselbe communityId im Body (wenn die Route sie verlangt) und im Header.
• Wiederholen macht nichts rückgängig: Bricht eine Abfolge mittendrin ab, mach bei dem Schritt weiter, der fehlgeschlagen ist, statt neu anzufangen (Neuanfangen erzeugt Duplikate).
• Im MCP werden die zusammengesetzten Werkzeuge diese Reihenfolge selbst einhalten.