---
title: "Approve WhatsApp group join requests"
method: POST
path: "/v1/whatsapp/groups/{group_id}/join-requests/batch-approve"
tags: ["whatsapp-groups"]
---

# Approve WhatsApp group join requests

`POST /v1/whatsapp/groups/{group_id}/join-requests/batch-approve`

## Request

- Base URL: `https://us1.platform.bird.com`
- URL: `https://us1.platform.bird.com/v1/whatsapp/groups/{group_id}/join-requests/batch-approve`
- Auth: one of:
  - HTTP bearer
  - API key in cookie `bird_session`

Approves the named join requests, up to 50 in one call.

WhatsApp decides each request on its own, so the batch can be part-applied:
the response lists the ones it accepted in `decided` and the rest in
`failed` with the reason each was refused. A refusal is usually a person
who has not accepted WhatsApp's current terms, which no retry fixes.

Each person approved can enter the group through its invite link. Re-read the
group to see who has arrived.

A group holds 8 participants besides your business. Approving more than the
group has room for does not refuse the call: the requests that fit are
decided and the rest come back in `failed`, each saying the approval would
take the group past its participant limit. A group that is not `active`
does refuse the whole call, with a `409` `WhatsAppGroupNotActive`.

## Path parameters

- `group_id` string, required

## Headers

- `Idempotency-Key` string
- `X-Workspace-Id` string
- `X-Organization-Id` string

## Request body

- WhatsAppGroupJoinRequestDecision: The join requests to decide on.
  - `join_request_ids` WhatsAppGroupJoinRequestID[], required: The join requests to act on, as returned by `GET /v1/whatsapp/groups/{group_id}/join-requests`. Each is decided on its own, so one can fail while the rest succeed. An ID that names no waiting request returns a `422` `WhatsAppGroupJoinRequestNotFound`. The 50 is Bird's own request bound, not a WhatsApp one: how many people the group can hold does not limit how many can queue at its link, so a rejection sweep is not held to the size of the group it is refusing entry to.

## Response `202`

What happened to each join request in the batch.

- WhatsAppGroupJoinRequestDecisionResult: What happened to each join request in the batch. WhatsApp decides them one by one, so a batch can be part-applied: the requests it accepted are in `decided`, and the rest are in `failed` with the reason.
  - `decided` WhatsAppGroupJoinRequestID[], required: The join requests WhatsApp accepted the decision for. A person approved here can enter the group; a person rejected here sees the join button again.
  - `failed` WhatsAppGroupJoinRequestFailure[], required: The join requests WhatsApp refused, each with its reason. Empty when the whole batch was applied.
    - `join_request_id` string, required
    - `error` WhatsAppGroupError, required: Why a change to a group did not take effect. Meta documents no code vocabulary for a group refusal, since every sample payload carries an undocumented `code` beside its message, so this relays what it said rather than classifying it, the way a template submission failure does.
      - `description` string, required: WhatsApp's own explanation of the refusal, passed through. Show it to the person who asked for the change; never match on its text. Carries Bird's own words instead when the failure was Bird's verdict, such as a confirmation that never arrived.
      - `meta_error_code` string, nullable: WhatsApp's most specific code for the refusal: its error subcode where it sent one, otherwise its top-level code. Treat it as an opaque string. Null when the failure was Bird's own verdict rather than a WhatsApp refusal.

## Other responses

- `400`: Bad request
- `401`: Authentication required
- `403`: Insufficient permissions
- `404`: Resource not found
- `409`: Resource conflict
- `422`: The request has invalid field values, violates a business rule, or carries a query parameter the endpoint does not declare. Field validation errors use `type: validation_error` and include the affected fields in `details`. Business-rule errors identify the failed rule in `type`.
- `429`: Rate limit exceeded
- `500`: Internal server error
- `503`: The service is temporarily unavailable. If `Retry-After` is present, wait for that delay before retrying; otherwise, retry with exponential backoff. Reuse the same idempotency key and request when retrying a mutation.

---

[API](https://skmtc.dev/messagebird/apis/bird-api.md) · [All operations](https://skmtc.dev/messagebird/apis/bird-api/llms.txt) · [OpenAPI document](https://skmtc.dev/messagebird/apis/bird-api/revisions/6dfce1179799?raw)
