Orden de creación

Casi todo en Memberfy depende de algo creado antes: la lección necesita el módulo, el módulo el curso, el curso el espacio. Llamar a la API fuera de orden no rompe nada, pero cada llamada adelantada se rechaza. Esta guía muestra el orden correcto y el id que pasa de una llamada a la siguiente.

#El mapa de dependencias

Dicho de otra forma:

En todas las llamadas de abajo van Authorization y X-CommunityId. Consulta Autenticación y X-CommunityId.

#Curso

1. Sección (si todavía no hay ninguna): POST /api/sections con title y visibility. Guarda data.id como sectionId.
2. Espacio de Cursos: POST /api/spaces con sectionId, title y module: "courses". Guarda el spaceId.
3. Curso: POST /api/courses con communityId (el mismo de la cabecera), spaceId, title, slug y level (beginner, intermediate, advanced). Nace como borrador. Guarda el courseId.
4. Módulos: POST /api/courses/module con courseId y title, uno por módulo. Guarda cada moduleId.
5. Lecciones: POST /api/courses/lesson con moduleId, title y type (text, image, video, link).
6. Publicar: PUT /api/courses/{id} con status: "published". Solo un curso publicado acepta matrículas.

Para ajustarlo después: PUT y DELETE /api/courses/module/{moduleId} renombran, reordenan y eliminan un módulo (con sus clases); PUT y DELETE /api/courses/lesson/{lessonId} cambian el título, el tipo, la duración y el orden de una clase, la llevan a otro módulo del mismo curso (moduleId) y la eliminan. Eliminar conserva el progreso de quien ya la vio.

Para vender el curso, sigue con un producto que abra el espacio (consulta Evento, pasos 3 y 4, que valen igual).

#Mentoría

Un grupo con su propio tablón, encuentros y cobro mensual. (Con la duración del contrato, la opción del paso 3 incorpora commitmentMonths.)

1. Espacio privado del grupo: POST /api/spaces con module: "feed" y visibility: "private". Guarda el spaceId.
2. Encuentros: POST /api/events, uno por encuentro, con spaceId, title, slug, type: "online", startTime y endTime.
3. Opción de cobro: POST /api/products con type: "SUBSCRIPTION", title, price, billingInterval: "MONTHLY" y allowedPaymentMethods. Guarda el id del producto.
4. Plan: POST /api/subscription-groups con name y productIds: [<id del paso 3>]. Guarda el id del plan.
5. Abrir el espacio al plan: PUT /api/spaces/{id} con access: { "subscriptionGroupIds": [<id del plan>] }.

El paso 5 solo funciona después del 4: el plan tiene que existir para poder citarlo en el acceso.

#Evento

Un evento presencial con entrada de pago y aviso en el Feed.

1. Espacio de Eventos: POST /api/spaces con module: "events".
2. Evento: POST /api/events con spaceId, title, slug, type: "in_person", startTime, endTime y la dirección (street, number, city…).
3. Entrada: POST /api/products con type: "ONE_TIME", price, hasStock: true y stockQuantity. Después, publícala.
4. Abrir el espacio a quien compró: PUT /api/spaces/{id} con visibility: "private" y access: { "productIds": [<id de la entrada>] }.
5. Aviso fijado: POST /api/content en el espacio del Feed, y PUT /api/feed/{type}/{id}/pin con el id de la publicación.

#Plan con adicionales

1. Opciones de cobro del plan: un POST .../products por opción (Mensual, Anual), type: "SUBSCRIPTION".
2. El adicional: otro POST .../products, type: "SUBSCRIPTION", billingInterval: "MONTHLY". No entra en los productIds de ningún plan.
3. Plan: POST .../subscription-groups con los productIds del paso 1.
4. Adicionales en el plan: PUT .../subscription-groups/{id} con addOnProductIds: [<id del paso 2>].

#Antes de vender: el cobro

Un orden que vale para cualquier venta:

1. POST .../business-information y .../submit.
2. POST .../payout-settings y .../submit.
3. Esperar las dos aprobaciones (hasta 7 días laborables). GET .../payout-settings/prerequisites dice lo que falta.

Los productos, las opciones, los planes, los adicionales, los cupones y las ofertas de downsell se pueden crear y editar antes de la aprobación: el producto nace DRAFT, con la moneda del país de la Información Empresarial (en cualquier estado) o BRL si no la hay. Publicar (POST .../products/{id}/publish, o PUT .../products/{id} con status: ACTIVE), el checkout y el retiro esperan la aprobación. Una Información Empresarial aprobada que se edita vuelve a PENDING y necesita .../submit de nuevo; hasta la nueva aprobación, el checkout rechaza los pagos.

#Los errores de quien se salta un paso

Con Accept-Language: es-ES, la mayoría de los mensajes llega en español; algunos llegan todavía en inglés o en portugués, y aquí aparecen tal como los devuelve la API.

Algunas validaciones de formato responden en inglés (como Valid course ID is required cuando el id no es un UUID).

#Consejos

• Guarda cada id que vuelve en data.id: es el que pide la llamada siguiente.
• Envía el mismo communityId en el cuerpo (cuando la ruta lo pide) y en la cabecera.
• Repetir no deshace: si una secuencia se para a medias, continúa desde el paso que falló, en lugar de empezar de nuevo (empezar de nuevo crea duplicados).
• En el MCP, las herramientas compuestas harán este orden por su cuenta.