Ordine di creazione

Quasi tutto su Memberfy dipende da qualcosa creato prima: la lezione ha bisogno del modulo, il modulo del corso, il corso dello spazio. Chiamare l'API fuori ordine non rompe nulla, ma ogni chiamata anticipata viene rifiutata. Questa guida mostra l'ordine giusto e l'id che passa da una chiamata alla successiva.

#La mappa delle dipendenze

Letto in un altro modo:

In tutte le chiamate qui sotto si inviano Authorization e X-CommunityId. Vedi Autenticazione e X-CommunityId.

#Corso

1. Sezione (se non c'è ancora): POST /api/sections con title e visibility. Conserva data.id come sectionId.
2. Spazio Corsi: POST /api/spaces con sectionId, title e module: "courses". Conserva lo spaceId.
3. Corso: POST /api/courses con communityId (lo stesso dell'header), spaceId, title, slug e level (beginner, intermediate, advanced). Nasce come bozza. Conserva il courseId.
4. Moduli: POST /api/courses/module con courseId e title, uno per modulo. Conserva ogni moduleId.
5. Lezioni: POST /api/courses/lesson con moduleId, title e type (text, image, video, link).
6. Pubblicare: PUT /api/courses/{id} con status: "published". Solo un corso pubblicato accetta iscrizioni.

Per sistemare in seguito: PUT e DELETE /api/courses/module/{moduleId} rinominano, riordinano ed eliminano un modulo (con le sue lezioni); PUT e DELETE /api/courses/lesson/{lessonId} cambiano titolo, tipo, durata e ordine di una lezione, la spostano in un altro modulo dello stesso corso (moduleId) e la eliminano. L'eliminazione conserva i progressi di chi l'aveva già seguita.

Per vendere il corso, prosegui con un prodotto che apre lo spazio (vedi Evento, passaggi 3 e 4, che valgono allo stesso modo).

#Mentoring

Una classe con una bacheca propria, incontri e addebito mensile. (Con la durata del contratto, l'opzione del passaggio 3 riceve commitmentMonths.)

1. Spazio privato della classe: POST /api/spaces con module: "feed" e visibility: "private". Conserva lo spaceId.
2. Incontri: POST /api/events, uno per incontro, con spaceId, title, slug, type: "online", startTime ed endTime.
3. Opzione di fatturazione: POST /api/products con type: "SUBSCRIPTION", title, price, billingInterval: "MONTHLY" e allowedPaymentMethods. Conserva l'id del prodotto.
4. Piano: POST /api/subscription-groups con name e productIds: [<id del passaggio 3>]. Conserva l'id del piano.
5. Aprire lo spazio al piano: PUT /api/spaces/{id} con access: { "subscriptionGroupIds": [<id del piano>] }.

Il passaggio 5 funziona solo dopo il 4: il piano deve esistere per poter essere indicato nell'accesso.

#Evento

Un evento in presenza con biglietto a pagamento e avviso nel Feed.

1. Spazio Eventi: POST /api/spaces con module: "events".
2. Evento: POST /api/events con spaceId, title, slug, type: "in_person", startTime, endTime e l'indirizzo (street, number, city…).
3. Biglietto: POST /api/products con type: "ONE_TIME", price, hasStock: true e stockQuantity. Poi pubblicalo.
4. Aprire lo spazio a chi ha acquistato: PUT /api/spaces/{id} con visibility: "private" e access: { "productIds": [<id del biglietto>] }.
5. Avviso fissato: POST /api/content nello spazio Feed, e PUT /api/feed/{type}/{id}/pin con l'id del post.

#Piano con componenti aggiuntivi

1. Opzioni di fatturazione del piano: un POST .../products per opzione (Mensile, Annuale), type: "SUBSCRIPTION".
2. Il componente aggiuntivo: un altro POST .../products, type: "SUBSCRIPTION", billingInterval: "MONTHLY". Non entra nei productIds di nessun piano.
3. Piano: POST .../subscription-groups con i productIds del passaggio 1.
4. Componenti aggiuntivi nel piano: PUT .../subscription-groups/{id} con addOnProductIds: [<id del passaggio 2>].

#Prima di vendere: il conto di accredito

Un ordine che vale per qualsiasi vendita:

1. POST .../business-information e .../submit.
2. POST .../payout-settings e .../submit.
3. Attendere le due approvazioni (fino a 7 giorni lavorativi). GET .../payout-settings/prerequisites indica che cosa manca.

Prodotti, opzioni, piani, componenti aggiuntivi, coupon e offerte di downsell si possono creare e modificare prima dell'approvazione: il prodotto nasce DRAFT, nella valuta del paese delle Informazioni Aziendali (in qualsiasi stato) oppure in BRL se non ci sono. La pubblicazione (POST .../products/{id}/publish, oppure PUT .../products/{id} con status: ACTIVE), il checkout e il prelievo aspettano l'approvazione. Delle Informazioni Aziendali approvate che vengono modificate tornano a PENDING e richiedono di nuovo .../submit; fino alla nuova approvazione, il checkout rifiuta.

#Gli errori di chi salta un passaggio

Alcuni messaggi arrivano ancora in inglese o in portoghese, qualunque sia l'Accept-Language (come Valid course ID is required quando l'id non è un UUID). Basati sullo status code e su param, non sul testo.

#Consigli

• Conserva ogni id che torna in data.id: è quello che chiede la chiamata successiva.
• Invia lo stesso communityId nel corpo (quando la rotta lo chiede) e nell'header.
• Ripetere non annulla: se una sequenza si interrompe a metà, riprendi dal passaggio fallito invece di ricominciare (ricominciare crea duplicati).
• Nell'MCP, gli strumenti composti seguiranno questo ordine da soli.