Ordem de criação

Quase tudo na Memberfy depende de algo criado antes: a aula precisa do módulo, o módulo do curso, o curso do espaço. Chamar a API fora de ordem não estraga nada, mas cada chamada adiantada é recusada. Este guia mostra a ordem certa e o id que passa de uma chamada para a seguinte.

#O mapa de dependências

Lido de outro jeito:

Em todas as chamadas abaixo vão Authorization e X-CommunityId. Ver Autenticação e X-CommunityId.

#Curso

1. Secção (se ainda não houver): POST /api/sections com title e visibility. Guarde data.id como sectionId.
2. Espaço de Cursos: POST /api/spaces com sectionId, title e module: "courses". Guarde o spaceId.
3. Curso: POST /api/courses com communityId (o mesmo do header), spaceId, title, slug e level (beginner, intermediate, advanced). Nasce como rascunho. Guarde o courseId.
4. Módulos: POST /api/courses/module com courseId e title, um por módulo. Guarde cada moduleId.
5. Aulas: POST /api/courses/lesson com moduleId, title e type (text, image, video, link).
6. Publicar: PUT /api/courses/{id} com status: "published". Só curso publicado aceita matrícula.

Para ajustar depois: PUT e DELETE /api/courses/module/{moduleId} mudam o nome, reordenam e eliminam um módulo (com as aulas); PUT e DELETE /api/courses/lesson/{lessonId} mudam o título, o tipo, a duração e a ordem de uma aula, passam a aula para outro módulo do mesmo curso (moduleId) e eliminam-na. Eliminar guarda o progresso de quem já a viu.

Para vender o curso, siga com um produto que libera o espaço (veja Evento, passos 3 e 4, que valem igual).

#Mentoria

Uma turma com mural próprio, encontros e cobrança mensal. (Com a duração do contrato, a opção do passo 3 ganha commitmentMonths.)

1. Espaço privado da turma: POST /api/spaces com module: "feed" e visibility: "private". Guarde o spaceId.
2. Encontros: POST /api/events, um por encontro, com spaceId, title, slug, type: "online", startTime e endTime.
3. Opção de faturação: POST /api/products com type: "SUBSCRIPTION", title, price, billingInterval: "MONTHLY" e allowedPaymentMethods. Guarde o id do produto.
4. Plano: POST /api/subscription-groups com name e productIds: [<id do passo 3>]. Guarde o id do plano.
5. Liberar o espaço para o plano: PUT /api/spaces/{id} com access: { "subscriptionGroupIds": [<id do plano>] }.

O passo 5 só funciona depois do 4: o plano precisa existir para ser citado no acesso.

#Evento

Um evento presencial com ingresso pago e aviso no Feed.

1. Espaço de Eventos: POST /api/spaces com module: "events".
2. Evento: POST /api/events com spaceId, title, slug, type: "in_person", startTime, endTime e o endereço (street, number, city…).
3. Ingresso: POST /api/products com type: "ONE_TIME", price, hasStock: true e stockQuantity. Depois, publique.
4. Liberar o espaço para quem comprou: PUT /api/spaces/{id} com visibility: "private" e access: { "productIds": [<id do ingresso>] }.
5. Aviso fixado: POST /api/content no espaço do Feed, e PUT /api/feed/{type}/{id}/pin com o id do post.

#Plano com adicionais

1. Opções de faturação do plano: um POST .../products por opção (Mensal, Anual), type: "SUBSCRIPTION".
2. O adicional: outro POST .../products, type: "SUBSCRIPTION", billingInterval: "MONTHLY". Ele não entra em productIds de plano nenhum.
3. Plano: POST .../subscription-groups com productIds do passo 1.
4. Adicionais no plano: PUT .../subscription-groups/{id} com addOnProductIds: [<id do passo 2>].

#Antes de vender: o recebimento

Uma ordem que vale para qualquer venda:

1. POST .../business-information e .../submit.
2. POST .../payout-settings e .../submit.
3. Esperar as duas aprovações (até 7 dias úteis). GET .../payout-settings/prerequisites diz o que falta.

Produtos, opções, planos, adicionais, cupões e ofertas de downsell podem ser criados e editados antes da aprovação: o produto nasce DRAFT, com a moeda do país da Informação Comercial (em qualquer estado) ou BRL sem ela. Publicar (POST .../products/{id}/publish, ou PUT .../products/{id} com status: ACTIVE), o checkout e o levantamento esperam pela aprovação. Uma Informação Comercial aprovada que seja editada volta a PENDING e precisa de novo de .../submit; até à nova aprovação, o checkout recusa.

#Os erros de quem pulou um passo

Algumas validações de formato ainda respondem em inglês (como Valid course ID is required quando o id não é um UUID).

#Dicas

• Guarde cada id que volta em data.id: é ele que a chamada seguinte pede.
• Envie o mesmo communityId no corpo (quando a rota pede) e no header.
• Repetir não desfaz: se uma sequência parar no meio, continue do passo que falhou, em vez de recomeçar (recomeçar cria duplicados).
• No MCP, as ferramentas compostas fazem essa ordem sozinhas.