> For the complete documentation index, see [llms.txt](https://developers.airship.co.uk/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers.airship.co.uk/basics/contacts/append-wifi-data.md).
# Append WiFi data
Store WIFI Interaction history as you send contact data to us
### Overview
Airship can store WIFI interaction history for each contact.
Having WIFI data attached to contacts is useful to measure and target recent or lapsed visitors based on their last visit.
### Storing WIFI interactions
To store WIFI interactions, simply append a `wifi_interactions` object to your contact as you send it to us.
| Value | Notes |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `datetime` | The date / time of the WIFI interaction
Required field
|
| `unit_id` | The unit\_id representing the physical location for which this WIFI interaction relates
Required field
|
| `type` | detected - This interaction type should be used when a user's device passively connects to the WiFi hotspot.
connected - This interaction type should be used once a user proactively views your captive portal.
authenticated - This interaction type should be used once a user has provided the information required by the captive portal to connect to the Internet via your WiFi service.
unknown - If your platform doesn't support the above connection types, use the unknown type
Required field
|
| `hotspot_name` | Text description of where the connection was made (i.e. Upstairs Bar)
Optional
|
| `mac_address` | Unique device reference
Optional
|
| `device_mime_type` | Text description for the source of the WIFI interaction
Required Field
|
### Example Payload
```json
{
"account_id": 3,
"email": "johnsmith@gmail.com",
//...etc...
"wifi_interactions" :[
{
"datetime":"2022-01-01 12:00:00",
"unit_id": "4",
"type": "authenticated",
"hotspot_name": "Bar 01",
"mac_address": "01:A1:C1:11:C1:11",
"device_mime_type": "Airship Splash page"
}
]
}
```
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://developers.airship.co.uk/basics/contacts/append-wifi-data.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.