---
uuid: 1bccb6d9-9a11-41f2-8292-8512a406c597
date_created: 2026-02-27T06:19:33.765Z
date_updated: 2026-04-08T12:53:36.988Z
seo_url: request-wifi-access
category: Services
tags: 
  - Transversal
  - Services
routes: 
  - POST /v1/wifi_access_request
---

# Request Wi-Fi access

This scenario documents how to transmit the information collected in a Wi-Fi access form through `POST /v1/wifi_access_request`. It fits a service-request journey where a channel captures the request and forwards it to Club Med for processing.

The documented response currently confirms whether the request is allowed with the `is_allowed` flag. The exact request body schema is not verifiable with the available source material, so the integration must align its payload with the backend contract used by the Wi-Fi form.

## Flow

false

## Overview

Use this scenario to document the submission of a Wi-Fi access request collected from a dedicated form. The route acts as the transmission point of the journey and exposes a simple confirmation response.

## Prerequisites

* A valid `x-api-key`
* A request payload aligned with the Wi-Fi access form contract
* A `product_id` in the payload, because the documented validation example shows it as required

## Expected result

The application can submit the Wi-Fi access request and determine whether the request is accepted for processing through the `is_allowed` flag returned on success.

## Scope notes

* This documented journey is intentionally limited to the submission endpoint because no complementary Wi-Fi access route is verifiable in the available source material.
* The detailed body schema and the downstream processing rules are not verifiable with the available source material.

## 1 - Transmit the Wi-Fi access request

#### Purpose

Use `POST /v1/wifi_access_request` to transmit the information entered in the Wi-Fi access form. This route is the submission point of the journey and returns whether the request is allowed.

#### Parameters

* **Required header**: `x-api-key`
* **Request body**: the exact schema is not verifiable with the available source material
* **Known validation clue**: the documented `400` example shows `product_id` as a required field in the payload

#### Example request

```bash
# The exact JSON body is not verifiable with the available source material.
curl -X POST \
  "https://api.clubmed.com/v1/wifi_access_request" \
  -H "x-api-key: YOUR_API_KEY" \
  --data-binary '<wifi access form payload>'
```

#### Response focus

```json
{
  "is_allowed": true
}
```

* `is_allowed` indicates whether the submitted Wi-Fi access request is accepted by the API
* A `200 OK` response confirms that the form information was transmitted in a format accepted by the endpoint

#### Errors and warnings

::::warning
:::
WARNING
:::

The exact request payload schema is not visible in the available source material. Confirm the backend contract used by the Wi-Fi form before implementation.
::::

* `400 bad_request` or `validation_error` indicates an invalid or incomplete payload
* The documented validation example explicitly mentions `FIELD_REQUIRED` on `product_id`
* Only `200` and `400` are verifiable from the available source material

**Related route**: [POST https://api.clubmed.com//v1/wifi\_access\_request](https://api.clubmed.com/doc?search=POST%20%2Fv1%2Fwifi_access_request)