Build a custom membership form

Embed campai's application form when you want its confirmation and review workflow. If your own backend handles admission, create the contact through REST after approval. A developer app Form group collects inputs for your app code; it does not automatically create a membership application.

Desired result	Integration approach
Use campai's application validation, confirmation, and review process	Use the application form's supported public link or website embedding options from campai.
Create contacts after an approval process you own	Submit to your own backend, validate and approve there, then call the CRM contact-creation API.
Collect inputs for code running inside campai	Build a developer app Form group. Implement any subsequent action explicitly.

The reviewed REST API can manage forms and review submissions, but has no external operation for submitting a new membership application. Use the public form for that workflow.

1. Open People → Applications → Forms and create or select the intended application form. For a new membership form, choose Members as the Contact type.
2. Configure the fields in Form and the submission behavior in Settings.

3. Open Share. Copy the public link or the website embed code shown there.

4. In your website editor, add a normal link using that exact public URL, or paste campai’s provided embed code into the editor’s HTML/embed block. Publish the page and open it in a signed-out browser session.

5. Follow the website link or embedded form as an applicant. Check required fields, confirmation, and any configured payment step.

6. Submit one designated test application, then return to People → Applications and verify it reached the intended review queue. Check its submitted fields before deliberately approving or rejecting the test application.

Your finished website flow: the visitor can open the configured form from your page, submit it, and reach its configured confirmation. Your team can find the corresponding submission for review. Do not mark this complete after merely copying the URL; test the published website entry point.

Existing submissions can be inspected through List submissions and Get submission, with application-submission read permissions. Accept submission and Reject submission are state-changing review actions. Calling them is a business decision, not part of a read-only status check.

Keep the application ID, submission ID, and eventual contact ID distinct in your database. They identify different records and are not interchangeable path parameters.

The public form uses an internal procedure with CAPTCHA, validation, and optional payment-method setup. Do not copy internal browser calls into an external integration. If a custom external submission API is essential, confirm a supported interface before building your frontend around it.

Select Mandates → Read and Application forms → Read on the key. Replace YOUR_API_KEY, YOUR_ORGANIZATION_ID, and YOUR_MANDATE_ID directly in your chosen example. Each tab is complete and uses only cURL or the runtime’s built-in functions.

List forms returns form metadata. This request reads one page of member application forms:

curl --fail-with-body --silent --show-error --max-time 30 --globoff \
  --request POST 'https://cloud.campai.com/api/YOUR_ORGANIZATION_ID/YOUR_MANDATE_ID/crm/applications/forms/list' \
  --header 'X-API-Key: YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data-raw '{
  "contactTypes": [
    "member"
  ],
  "sort": {
    "_id": "asc"
  },
  "limit": 50,
  "offset": 0
}'

For additional pages, increase offset by 50 until fewer than 50 forms are returned. Keep a map keyed by _id if you combine pages.

An empty array is a valid result when no matching form exists in the accessible mandate. For one form's definition, use Get form with its applicationFormId. Keep administrative configuration server-side; reading a definition does not grant anonymous visitors a submission endpoint.

Your website should submit to your own server, which validates inputs, applies abuse protection, records the required consents, and performs your approval process. Only after approval should it use Create contact with type: 'member' and a payload matching the current schema.

Contact creation returns a contact _id and a nullable debtor account. It does not create a pending application or reproduce the native form's confirmation and payment-method flow. Creating or attaching a debtor requires separate permissions and an explicit choice.

Persist the external application ID and returned contact ID before marking the application complete. Do not blindly retry a timed-out create: reconcile the uncertain result first. The makeDuplicateCheck option is not a substitute for an integration's durable operation ledger or a reviewed identity match.

Test an incomplete submission, repeated submit, confirmation failure, approval, rejection, and a resumed session. Use synthetic data. Confirm which record exists at each stage and which notifications or payment actions the configured workflow produces. For an external admission process, verify that failed validation creates no contact and that a lost response cannot create two contacts.