WhatsApp Group Join Approval: Enable or Disable It via API

To enable or disable WhatsApp group join approval through UnifyPort, send POST /v1/accounts/{account_id}/groups/join-approval-mode with group_id and the required boolean enabled. Use true to require approval and false to turn that requirement off. This changes a group setting; it is not an approve-all or reject-all operation for pending requests.

Key takeaways

• Treat the setting as an explicit administrative decision, not a side effect of opening the moderation queue.
• Send a JSON boolean, not the string "false", an omitted checkbox, or a guessed toggle action.
• The current UnifyPort operation supports whatsapp, not the separate whatsapp-protocol provider or other channels.
• Keep the requested setting, the API result, and any later verification separate.

Choose the setting, not a moderation action

Meta’s official explanation of WhatsApp group controls describes giving admins control over who can join when they share a group invitation link or make a group joinable in a community. The platform control and the software that reviews applicants are different layers.

Use the following decision table before adding a button:

Operator intention	Appropriate operation
Require approval for new entrants	Set approval mode with enabled: true
Turn off the approval requirement	Set approval mode with enabled: false
Accept or decline selected pending applicants	Use the separate join-request update operation
Retrieve an invitation URL	Use the invite-link read operation

For applicant-by-applicant decisions, continue with the WhatsApp join-request approval queue. For distributing invitations, use the invite-link read versus reset guide. Neither workflow should silently change the group’s admission policy.

Build an explicit enable/disable form

The approval-mode reference documents a required boolean enabled alongside group_id. The provider action matrix limits this operation to WhatsApp. UnifyPort provides an unofficial interface for a connected messaging account; this is not a WhatsApp Cloud API request.

Select the account and group together. Use List groups to obtain the group identifier rather than identifying the target only by its name. Confirm that the connected identity is an authorized group administrator and that your own application permits this operator to change admission policy. Possessing a workspace API key is not itself group-admin authority.

Recommended form behavior:

1. Show the selected account and group in the confirmation screen.
2. Require an explicit choice between enabling and disabling approval.
3. Keep an unknown current setting visibly unknown; do not render missing information as “off.”
4. Send only the chosen value when the operator confirms. Do not write on page load or queue refresh.
5. Preserve false during validation and serialization. A truthiness check can accidentally discard the disabling value.

The public group-read example does not document an approval-mode field. Do not invent a response property to prefill the form. Where your integration has no documented readback, ask an authorized admin to inspect the setting in WhatsApp and label your application’s last requested value accordingly.

Submit one deliberate setting change

This illustrative server-side JavaScript uses actual request fields. It is not an executed integration test and deliberately contains no automatic retry:

export async function setJoinApproval({ apiKey, accountId, groupId, enabled }) {
  if (!apiKey || !accountId || !groupId || typeof enabled !== 'boolean') {
    throw new Error('Account, group, credential and boolean choice required');
  }

  const response = await fetch(
    `https://api.unifyport.ai/v1/accounts/${encodeURIComponent(accountId)}/groups/join-approval-mode`,
    {
      method: 'POST',
      headers: { 'X-Api-Key': apiKey, 'Content-Type': 'application/json' },
      body: JSON.stringify({ group_id: groupId, enabled })
    }
  );
  const requestId = response.headers.get('X-Request-Id');
  const body = await response.json();
  return { httpStatus: response.status, requestId, body };
}

Keep the key on the backend. The return names httpStatus, requestId, and body are local application names, not new API response fields. The documented successful response is 200 OK with data.ok: true. Save the intended boolean and the result before showing success. Catch network and JSON parsing failures in the caller; a missing response must remain unresolved rather than becoming “disabled.”

Serialize changes for the same account and group within your application. If one operator requests enable and another later requests disable, a delayed retry of the earlier request could restore an obsolete choice. A local lock or revision check is an application safeguard, not a documented upstream conditional-write feature. Native-app admins can still make independent changes.

Verify policy separately from pending requests

An empty pending list does not prove approval is off. It may simply mean nobody is waiting. Likewise, a group.join_request event is a request signal, not an acknowledgement of your setting change. The public event contract does not promise a dedicated approval-mode confirmation callback.

After enabling, have an authorized admin check the setting and use a controlled invitation test before distributing the link widely. Continue polling List group join requests for moderation; its documentation makes clear that push signals are best-effort.

Before disabling, review outstanding requests and decide who will reconcile them afterward. The approval-mode contract does not specify how disabling affects existing pending requests. Do not claim that it accepts everyone, rejects everyone, removes current members, or resets invitation links. Use explicit moderation operations for individual decisions.

If the setting request times out, retain the intended value and diagnostic evidence, check the native setting, and ask for a fresh decision before resubmitting. Do not automatically send the opposite value as a supposed rollback: another administrator may already have changed the policy.

FAQ

Can I omit enabled to leave the setting unchanged?

No. This operation requires a boolean. If no change is intended, do not call it.

Does enabled=false reject everyone waiting?

That is not documented. Treat disabling the setting and resolving existing requests as separate tasks.

Can my moderation worker enable approval on every poll?

It should not. Polling is observation; configuring admission policy is an administrative write. Keeping them separate prevents a worker from undoing an admin’s deliberate choice.

Does this operation work for Telegram or LINE?

Not according to the current UnifyPort action matrix. A common route shape does not establish channel support.

Next step and sources

Implement the form against Set group join approval mode. Proposed acceptance tests should include both boolean values, string input rejection, unknown initial state, concurrent opposite choices, and a lost response. These are recommended checks, not reported test results.

References checked on 2026-11-02:

• Meta: Getting More Out of Groups on WhatsApp
• UnifyPort: Set group join approval mode
• UnifyPort: Provider action support
• UnifyPort: List group join requests