Hello,
I have a Hap Mini (RB931-2nD) that I would like to use as a "dumb switch": It should connect wiressly to an access point and provide network access to wired devices connected to it. It shouldn't have a DHCP server, nor Firewall, etc. It should be transparent to the network (it would be nice to be able to manage it from the same network, but this is not mandatory). How can I achieve this?
Thank you!, (and sorry for my lack of networking knowledge/ proper lexicon)

It depends if the access point you're going to connect to is a) also Mikrotik, b) is a legacy wireless device.
I.e. not AX line nor arm-based AC device using wave2 drivers. I am not 100% sure if it will work with wave2 devices. There have been some changes lately on wifiwave2 side but I am not sure it will allow mixing legacy and wave2 wifi.
It should definitely work with legacy wifi devices.

If both conditions are true, you can add all interfaces to bridge, remove all firewall and interface lists, use DHCP client on bridge (for easier access later on) and connect wifi interface in station-bridge mode to the other AP.

If not (mainly if other AP is not Mikrotik), you can use station mode, remove wifi interface from bridge, DHCP client on wifi interface, foresee all required routing functions for all ethernet ports on bridge (DHCP, route, DNS, ...).

Hello holvoetn. Thank you for your help.
I've followed the last bit since it is similar to my setup. I've managed to connect the Hap Mini to the access point and get an IP from the DHCP server on the network, as well as DNS (tested from the Hap Mini's terminal), but I'm not sure how to proceed so the LAN ports get an IP address from the DHCP server as well. Could you give me more details about what you mean with

foresee all required routing functions for all ethernet ports on bridge (DHCP, route, DNS, ...)

Thanks!

Problem with your "dumb switch" , is that for this to work the switch must do some smart special things, if the data over wifi is for multiple cabled devices.

Not as in a normal cabled "dumb switch" where the data-packets keep their original source/destination MAC addresses, as these are also the transmitter/receiver MAC addresses. A wifi link (802.11) has other transmitter/receiver than the source/destination. Not a problem normally, but the 802.11 standard only defines 3 MAC addresses in a packet. Source, transmitter and only one MAC address for the receiver (supposed to be the destination).

There are solutions for this, but they are vendor and software specific. The 4 address-mode is active between MT wifi , if both run the WLAN driver, or both use the wifiwave2-driver, and the 4-address mode is triggered (set as AP-bridge and station-bridge with WLAN, the wifiwave2 AP will react on the station-bridge of the wifiwave2 (only)). All other cases is 3-address mode. ( WDS is another wifi 4-address mode)

There are 3 solutions for this 3-address mode ...
1. Use the router function on the wifi-station (normally with NAT). The AP will send all data to the station IP/MAC address That station will forward/reverse NAT/route the answer to the proper device. Behind NAT, the devices must take the initiative for the communication, to make the proper entries in the FW connection table. Or a set of DST-NAT addresses/ports must be configured. (manual table).
2. One can create a L2 tunnel between the wifi AP and station. The outer skin of the tunnel carries the IP/MAC addresses of AP and wifi station only. Inside the tunnel, it is like an ethernet cable.
3. The third possibility is to make that "dumb switch" smarter, and let it do the dispatching, based on IP addresses (not on MAC addresses). Intelligence is gathered when the clients on the cable transmit packets via the wifi-station. That is the "station-pseudobridge" use case. For a single wired device "station-pseudobridge-clone MAC" is expected to work a bit better. (receiver MAC = destination MAC)

The 3th solution is problematic. As network-software developpers do not expect to see different devices' IP addresses with all the same MAC. DHCP is such a software dilemma. MAC addresses in the packet-headers should not be used , but the MAC addresses in the payload are for DHCP. In all the other cases, DHCP header and payload MAC are identical, not in this "L2.5" pseudo-bridge case. Where the DHCP server has to send the DHCP offer as answer? To payload or header MAC? Header MAC is wrong, but payload MAC will never reach its destination, unless flooding is used.

Some solutions work with "proxy arp". Results do vary, and DHCP is among the first network functions to fail. Results are timing dependent (cached info gets flushed), difficult to diagnose. Using wifi-repeaters bring similar problems. (Everyone behind the repeater uses the same Hotspot MAC-cookie, FW gets confused, etc ...)

One AP to many clients on the station is the problem. Wifi stations with just one destination is easy.
Many very cheap solutions do exist for that. (Sometimes as secondary function, in over-powerline links with AP function, ethernet repeaters/extenders tend to gave an ethernet port as well)

There is of course the hAP Lite, or the small mAP Lite, but even the MQS had this function. (Had ... because it is discontinued, was sold as a limited AP, but is also a station.)
MQS sets the point ... an ESP8266, ESP32, or ESP32-C6) will do the trick.
ESP32C6 is new, and is wifi6.

I'm very sorry for taking so long to respond. I had to travel, and couldn't try any more suggestions, but next week I'll be back and have it working (hopefully). Thank you bpwl and holvoetn!