WiFi QR Code API Guide

A Wi-Fi QR code does not encode a URL. It encodes a plain-text configuration string that phone cameras recognise and offer to act on, in this shape:

WIFI:T:WPA;S:MyNetwork;P:MyPassword;H:false;;

The fields:

• T: — security type. WPA covers WPA, WPA2 and WPA3 for scanning purposes. WEP for legacy networks. nopass for an open network.
• S: — the SSID (network name), exactly as broadcast, case-sensitive.
• P: — the password. Omit it entirely for nopass networks.
• H: — true if the SSID is hidden, false or omitted otherwise.
• The double semicolon ;; terminates the string and is required.

Field order is not significant — WIFI:S:...;T:...;P:...;; is equally valid. SMLLR writes them in T, S, P, H order.

Because this is raw configuration data rather than a URL, there is genuinely no server involved and no wifi qr code api in the web-service sense. The "API" is this string format plus whatever library you use to turn it into an image.

This is the single most common source of Wi-Fi QR codes that silently fail, and it is worth getting exactly right.

The characters \, ;, ,, : and " are special within the WIFI: format and must be escaped with a backslash when they appear inside an SSID or password. A password of Guest;2026 must be encoded as Guest\;2026, or the parser will treat the semicolon as a field terminator and read a truncated password.

This matters in India more than it might elsewhere, because generated router passwords from ISP-supplied equipment frequently contain exactly these characters. A guest who scans a code with an unescaped semicolon gets a failed connection with no useful error — the phone simply reports a wrong password.

One further edge case: an SSID consisting only of hexadecimal characters can be ambiguously interpreted as a hex-encoded value rather than a literal string. The convention is to wrap such an SSID in double quotes — S:"ABCD1234"; — to force literal interpretation. Rare, but genuinely breaks when it happens.

For a hotel with 200 rooms, an office with per-floor guest networks, or a coworking operator with a network per location, you generate these in your own backend.

Python, with escaping handled properly:

import qrcode

SPECIAL = ['\\', ';', ',', ':', '"']

def esc(value: str) -> str:
    for ch in SPECIAL:
        value = value.replace(ch, '\\' + ch)
    return value

def wifi_qr(ssid: str, password: str, security: str, hidden: bool, out_path: str):
    payload = f"WIFI:T:{security};S:{esc(ssid)};P:{esc(password)};H:{str(hidden).lower()};;"
    qrcode.make(payload).save(out_path)

wifi_qr("HotelGuest_301", "Stay;Well2026", "WPA", False, "room_301.png")

Note that the escape function runs on the SSID and password but not on the assembled payload — escaping the whole string would break the field delimiters themselves.

Our Python QR code API guide covers library options and output formats in more depth, including exporting vector files for print.

Wi-Fi QR support is good on modern phones but not universal, and the failure modes are worth knowing before you print 200 room cards:

• iOS and modern Android both recognise the WIFI: format from the native camera and offer a join prompt. This covers the large majority of guests.
• Older Android devices may require a dedicated scanner app, or may not support it at all. On an entry-level handset a few years old, the camera may simply display the raw string.
• Enterprise networks using WPA2-Enterprise or 802.1X authentication are not covered by this format. There is no field for a username or certificate. If your guest network requires a login portal, a Wi-Fi QR code cannot bypass it.
• Captive portals. A code can join the network, but if you run a captive portal the guest still has to complete it. Say so on the card, or you will generate support calls from people who think the code failed.

Practical mitigation: print the SSID and password as legible text alongside the code. It costs nothing, and it converts a total failure into a mild inconvenience for the minority of guests whose device cannot use the code.

A Wi-Fi QR code contains your network password in plain text inside the printed pattern. Anyone who scans it has the password. Anyone who photographs it has the password, permanently, until you change the network password itself.

This is not a flaw to be engineered away — it is what the format is. It has three direct consequences for how you deploy at scale:

• Rotate and reprint together. Any password rotation policy means regenerating and reprinting every affected code. Build that cost into the policy before you commit to it, especially for a 200-room hotel.
• Separate the guest network. The code should carry guest-network credentials, never your operational or point-of-sale network. This is basic segmentation and it matters more the more widely the code is displayed.
• A Wi-Fi QR can never be dynamic. Because the credentials are in the pattern rather than behind a redirect, there is no way to update it remotely. This is the one QR use case where the reprint problem genuinely cannot be solved by a dynamic code — our Wi-Fi QR code guide covers the placement side of this.

For a hotel, the workable pattern is a stable guest SSID with a password rotated on a planned schedule that lines up with when room collateral is reprinted anyway.

Wi-Fi payloads are usually 40–80 characters, which sits comfortably in a low QR version with large, easy-to-scan modules. Two things inflate that unnecessarily:

• Long generated passwords. A 32-character random ISP password roughly doubles the payload versus a 12-character memorable one, pushing the code to a higher version with smaller modules — worse for the older cameras most likely to struggle already.
• Escaped special characters. Each escape adds a backslash, so a password dense with ; and : costs more payload than its visible length suggests.

For a guest network specifically, a memorable 10–14 character password without special characters is usually the better engineering choice: shorter payload, sparser code, better scan rate, and legible when printed as fallback text. Our data capacity guide covers the version-to-capacity relationship in detail.

In the dashboard, Wi-Fi is a QR type available from the Starter plan (₹499/month). You enter the SSID, password, security type and hidden flag; SMLLR assembles the WIFI: payload in T, S, P, H order.

The SMLLR REST API cannot generate Wi-Fi QR codes — or any QR codes. The public API is read-only reporting: seven GET endpoints covering account summary, QR codes, campaigns and agency clients, on the Premium plan (₹14,999/month), limited to 60 requests per minute per key. For programmatic bulk generation of Wi-Fi codes, use a QR library in your own backend as shown above.

One more honest note specific to this type: because a Wi-Fi code encodes raw configuration rather than a URL, it produces no scan analytics at all. Nothing touches SMLLR's servers when a guest joins your network. If you want to know how many guests used the Wi-Fi, that data lives in your router or access-point management system, not in a QR dashboard.

Create your QR code on SMLLR with the Wi-Fi type, and print the credentials as fallback text alongside it.