WiFi Pineapple - 6th Gen: NANO / TETRA
  • WiFi Pineapple NANO/TETRA
  • Getting Started
    • About the WiFi Pineapple NANO/TETRA
    • The WiFi Auditing Workflow
    • The PineAP Suite
    • The Web Interface
    • Upgrading the Firmware
  • Setup
    • Setup Basics
    • WiFi Pineapple NANO - Linux Setup
    • WiFi Pineapple NANO - Windows Setup
    • WiFi Pineapple TETRA - Linux Setup
  • Internet Connectivity
    • Internet Connectivity Basics
    • Internet Connection Sharing on Kali Linux
    • Internet Connection Sharing over Ethernet in Windows
    • Internet Connection Sharing over Ethernet in Linux
    • Wired Internet Connection
    • WiFi Client Mode
  • Console Access
    • Console Access Basics
    • Secure Shell
    • Serial Access - WiFi Pineapple TETRA
    • Working with PineAP from the CLI
  • Basics of WiFi Operation
    • Basics of WiFi Operation
    • Radios and Chipsets
    • Stations and Base Stations
    • Transmit Power
    • Channels and Regions
    • Protocols
    • Modes of Operation
    • Logical Configurations
    • MAC Address
    • Broadcast Address
    • Service Sets and Identifiers
    • Management Frames
    • Frame Types
    • Frames and Frame Structure
    • Frame Injection
    • Association States
  • FAQ / Troubleshooting
    • Serial Console on the WiFi Pineapple TETRA
    • Ethernet on the WiFi Pineapple TETRA
    • LED Status Indicators
    • Power Considerations
    • Factory Reset
    • Firmware Recovery
    • Manual Firmware Installation
  • Development
    • Legacy WiFi Pineapple Mark V Modules (Infusions)
    • Specifications and Power Considerations
    • WiFi Pineapple NANO/TETRA Module API - Introduction
    • WiFi Pineapple NANO/TETRA Module API - Authentication
    • WiFi Pineapple NANO/TETRA Module API - Modules
    • WiFi Pineapple NANO/TETRA Module API - module.php API
    • Creating WiFi Pineapple NANO/TETRA Modules
Powered by GitBook
On this page
  1. Development

WiFi Pineapple NANO/TETRA Module API - Introduction

Unlike the old web interface, the back end of the new interface has been decoupled from the front end. All requests to perform system actions are sent as POSTs to /api/. The content of the POST is JSON and contains a minimum of two parameters.

THE FIRST PARAMETER KEY MUST BE EITHER SYSTEM OR MODULE

system is used for core system functions such as logging users in and performing system setup as well as managing notifications. module is used when sending a request to any of the default modules or to any user modules. The value is set to the module with which you are trying to communicate. For example, "system": "notifications" or "module": "RandomRoll".

THE SECOND PARAMETER KEY ACTION

This is set to the action you wish to perform. For instance, this could be "action": "listNotifications" or "action": "getRandomRollRolls".

ANY OTHER PARAMETERS ARE OPTIONAL AND ARE SPECIFIC TO THE MODULE AND ACTION YOU ARE REQUESTING

Many actions do not require additional parameters. For instance, {"system": "notifications", "action": "listNotifications"} will return a list of all of the current unread notifications (as JSON). However, there are some functions, such as addNotification, that require additional parameters (in this case message). To create a new notifications, one would use the following request:

{
  "system": "notifications",
  "action": "addNotification",
  "message": "Hello World!"
}
PreviousSpecifications and Power ConsiderationsNextWiFi Pineapple NANO/TETRA Module API - Authentication

Last updated 3 years ago