Creation order

Almost everything on Memberfy depends on something created earlier: a lesson needs a module, a module needs a course, a course needs a space. Calling the API out of order doesn't break anything, but every call made too early is refused. This guide shows the right order and the id that passes from one call to the next.

#The dependency map

Put another way:

Every call below carries Authorization and X-CommunityId. See Authentication and X-CommunityId.

#Course

1. Section (if there isn't one yet): POST /api/sections with title and visibility. Keep data.id as the sectionId.
2. Courses space: POST /api/spaces with sectionId, title and module: "courses". Keep the spaceId.
3. Course: POST /api/courses with communityId (the same as in the header), spaceId, title, slug and level (beginner, intermediate, advanced). It starts as a draft. Keep the courseId.
4. Modules: POST /api/courses/module with courseId and title, one per module. Keep each moduleId.
5. Lessons: POST /api/courses/lesson with moduleId, title, type (text, image, video, link) and the content: body (formatted text) for a text lesson, contentUrl for video, link and image lessons. Video accepts only YouTube, Vimeo and Loom (another provider becomes type: link), and duration is mm:ss or hh:mm:ss.
6. Publish: PUT /api/courses/{id} with status: "published". Only a published course accepts enrollments.

A single course. In step 2, send moduleConfig: { "mode": "single" } and, with it, course (title, level, description): the space and the course are created in one transaction (nothing is left created if the course fails), and the course comes back in data.course, as a draft. In a single space that already has a course, step 3 returns 409 on the spaceId field (drafts and archived courses count). Switching a space from list to single with 2 or more courses also returns 409, on the moduleConfig.mode field; from single to list always goes through.

Certificate on completion. Step 3 and the PUT accept the certificate block (enabled, templateId, text); templateId must be an active template of the same community, found in GET /api/certificates/templates (without spaceId, for owner and admin). See Courses.

Batch order. PUT /api/courses/{courseId}/modules/order and PUT /api/courses/module/{moduleId}/lessons/order record the order of all modules (or of the lessons of a module) in one call. The list is the complete one; if an item is missing or repeated, 400 (moduleIds/lessonIds) and nothing changes.

Students. GET /api/courses/{id}/enrollments, paginated, for owner, admin and moderator. POST /api/courses/{id}/enrollments (with memberId) enrolls someone else in a free course, for the same roles; on a paid course: 403.

To adjust it later: PUT and DELETE /api/courses/module/{moduleId} rename, reorder and delete a module (along with its lessons); PUT and DELETE /api/courses/lesson/{lessonId} change a lesson's title, type, duration and order, move it to another module of the same course (moduleId) and delete it. Deleting keeps the progress of whoever already watched it.

On the student side: POST /api/courses/{courseId}/enroll enrolls the caller (201 the first time; afterwards 200 with the enrollment that already exists, with no extra points) and POST /api/courses/{courseId}/lesson/{lessonId}/progress with completed: true completes the lesson (completed: false only records the access and never un-completes). The course GET returns each lesson's body and contentUrl only to owner, admin, SuperAdmin or an enrolled student; everyone else gets the outline, with those keys absent.

To sell the course, continue with a product that opens the space (see Event, steps 4 and 5, which work the same way).

#Mentoring

A cohort with its own board, sessions and monthly billing. (With contract length, the option in step 3 gains commitmentMonths.)

1. The cohort's private space: POST /api/spaces with module: "feed" and visibility: "private". Keep the spaceId.
2. Sessions: POST /api/events, one per session, with spaceId, title, slug, type: "online", startTime, endTime and publish: true (without it, the session stays a draft).
3. Billing option: POST /api/products with type: "SUBSCRIPTION", title, price, billingInterval: "MONTHLY" and allowedPaymentMethods. Keep the product's id.
4. Plan: POST /api/subscription-groups with name and productIds: [<id from step 3>]. Keep the plan's id.
5. Open the space to the plan: PUT /api/spaces/{id} with access: { "subscriptionGroupIds": [<plan id>] }.

Step 5 only works after step 4: the plan has to exist before access can refer to it.

#Event

An in-person event with a paid ticket and an announcement in the Feed.

1. Events space: POST /api/spaces with module: "events".
2. Event: POST /api/events with spaceId, title, type: "in_person", startTime, endTime and the address (street, number, city…). The event is created as a draft: only the team sees it, and nothing is announced. Adjust whatever is missing with PATCH /api/events/{id} (send the updatedAt of the last answer).
3. Publish: POST /api/events/{id}/publish with notifyByEmail (true e-mails whoever can see the event). If something is missing, 422 with the fields in errors[]. Publishing puts the draft ticket types on sale; a paid type only with approved Business Information. To create and publish in a single call, as before, send publish: true in step 2 (then slug is required too).
4. Ticket: POST /api/products with type: "ONE_TIME", price, hasStock: true and stockQuantity. Then publish it.
5. Open the space to buyers: PUT /api/spaces/{id} with visibility: "private" and access: { "productIds": [<ticket id>] }.
6. Pinned announcement: POST /api/content in the Feed space, then PUT /api/feed/{type}/{id}/pin with the post's id.

To register someone for a free event on behalf of the team: POST /api/events/{id}/registrations (with memberId; owner, admin and moderator), with the rules of the person's own registration; on an event that charges them: 403. To notify up to 100 people in the bell: POST /api/notifications/send (memberIds, title, body; same roles).

For the event to issue a certificate, send the certificate block with enabled: true in step 2 (or later, in a PATCH); endTime is required and must be after startTime. Without templateId, the Platform default applies. See Attendance certificate.

#Plan with add-ons

1. The plan's billing options: one POST .../products per option (Monthly, Annual), type: "SUBSCRIPTION".
2. The add-on: another POST .../products, type: "SUBSCRIPTION", billingInterval: "MONTHLY". It does not go into any plan's productIds.
3. Plan: POST .../subscription-groups with the productIds from step 1.
4. Add-ons on the plan: PUT .../subscription-groups/{id} with addOnProductIds: [<id from step 2>].

#Before selling: payouts

An order that applies to any sale:

1. POST .../business-information and .../submit.
2. POST .../payout-settings and .../submit.
3. Wait for both approvals (up to 7 business days). GET .../payout-settings/prerequisites tells you what's missing.
4. Turn on the community's sales: PATCH /api/communities/{id}/settings with payoutEnabled: true. The route checks the approved business and payout details and the active payout account, and refuses with 400 on the field for whatever is missing. The sign-up model (signupModel) also changes only here.

PUT /api/communities/{id} stops accepting payoutEnabled and signupModel. Sending them returns 400 with param on the field itself ("This field is changed in the community settings (PATCH /api/communities/{id}/settings).") and nothing is saved. In the same PUT, signupEnabled, guestAccess, contentModeration, globalRanking and active must be true or false; any other type returns 400. Anyone who turns on sales or changes the sign-up model through the PUT moves to PATCH .../settings.

Products, billing options, plans, add-ons, coupons and downsell offers can be created and edited before approval: the product starts as DRAFT, in the currency of the Business Information's country (in any status), or BRL without it. Publishing (POST .../products/{id}/publish, or PUT .../products/{id} with status: ACTIVE), checkout and withdrawals wait for approval. An approved Business Information that gets edited goes back to PENDING and needs .../submit again; until it's approved again, checkout refuses.

#Custom domain

The community's address no longer changes through PUT /api/communities/{id}. The domain field is now the primary address, written only by Memberfy: the active custom domain or, without one, the Memberfy subdomain. The PUT accepts a domain equal to the current value (ignoring case and spaces) and ignores it, because a form usually sends everything back; a different value returns 400 with param: "domain" (The community address can't be changed here. Use the custom domain settings.) and nothing is saved. In POST /api/communities, domain is ignored.

The custom domain has its own routes, for the owner and the admin of the X-CommunityId community (moderator, finance and member get 403). See Custom domain.

The order:

1. PUT .../custom-domain with the hostname.
2. Create the pending.record record in DNS: type (CNAME, or ALIAS on @ for a root domain), name and target. The target is unique to each domain: use the one the response returns.
3. Follow pending.status with the GET: PENDING_DNS → VERIFYING → CERT_ISSUED → ACTIVE (or FAILED). Each step has its date (requestedAt, checkedAt, dnsVerifiedAt, certIssuedAt, activeAt, failedAt), and expiresAt is the 7-day deadline. Checks run on their own (every minute for the first 10, then every 5); POST .../check speeds it up.
4. At ACTIVE, the domain moves to active and becomes the primaryDomain. Before that, it doesn't open the community.

With an active domain, a PUT with another hostname is a change without downtime: the old one stays in active until the new one becomes active, and only then is it removed. Sending the active one's hostname gives up the change; sending another one in place of a pending one replaces it.

The check error comes in pending.error, with a code and the translated message (show it as it comes):

The PUT refusals (with param: "hostname"):

DELETE and POST .../check with no domain to remove or check return 404 (The community has no custom domain being set up.). The Memberfy team has the same routes for any community, at /api/admin/communities/{communityId}/custom-domain, which, like every /api/admin route, stay out of the public reference.

#SMS and WhatsApp

For a notice to reach the phone, this is the order. See SMS and WhatsApp notices.

1. Turn the channel on (owner or admin): PUT /api/sms/settings or PUT /api/whatsapp/settings with { "enabled": true, "dailyCap": 500 }. Without dailyCap (from 1 to 50,000), 422 with param: "dailyCap". SMS comes from Growth up and WhatsApp on Business and Scale (availableOnPlan on read). On SMS, personDailyCap (1 to 20, 5 by default) limits workflow messages per person per day; on WhatsApp, moments turns platform messages off for the community.
2. The person's consent: smsConsent on POST /api/auth/register ({ "service": true, "marketing": false, "whatsapp": { "service": true, "marketing": false } }, with phone and phoneCountry) or on POST /api/auth/login; or the import's smsConsent (or whatsappConsent) column, with the attestation, for new people and for existing members; or POST /api/contact-consent/attestations (owner and admin), with attestation: true, for consent the community declares it collected from existing members (the phone provided can receive SMS and WhatsApp right away, without being verified; the response has sendable per member); or PUT /api/members/me/notice-preferences with sms.enabled: true (or whatsapp.enabled: true) and sms.textVersion (or whatsapp.textVersion) set to the version of sms.all (or whatsapp.all): one switch per channel, recording notices and news together; enabled: false withdraws both. The texts the person sees come from GET /api/contact-consent/texts.
3. Verify the phone (the person): POST /api/members/me/phone-verification (with phone or the account's phone) and POST /api/members/me/phone-verification/confirm with the code. The code goes on WhatsApp when the community has WhatsApp on, and by SMS when it doesn't; data.sentVia tells the channel (whatsapp or sms). With neither on, 409 sms.otpNoChannel.
4. Test: POST /api/sms/test or POST /api/whatsapp/test sends to your phone and answers 202 with queued (and when it goes out) or skipped and the reason.
5. Use: the sendSms and sendWhatsapp blocks of workflows (sendWhatsapp with template, variables and link: always an approved template) and, on WhatsApp, the platform messages.

#The errors you get when you skip a step

Some format validations still answer in English regardless of language (like Valid course ID is required when the id isn't a UUID).

#Tips

• Keep every id that comes back in data.id: it's what the next call asks for.
• Send the same communityId in the body (when the route asks for it) and in the header.
• Repeating doesn't undo: if a sequence stops halfway, continue from the step that failed instead of starting over (starting over creates duplicates).
• In the MCP, the composite tools will follow this order on their own.