Writes

PUT, POST and DELETE work on organizations, networks, devices, admins, VLANs, firewall and NAT rules, static routes, site-to-site VPN, hub BGP, third-party VPN peers and their IPsec SLA policies, VPN firewall rules, threat protection and the organization's allowed intrusion rules, SSIDs and their firewall, splash, Bonjour, Hotspot 2.0, schedule, traffic shaping and VPN settings, identity PSKs, RF profiles, radio settings, switch ports, switch stacks and their layer 3 interfaces, DHCP and static routes, a switch's own layer 3 interfaces and static routes, switch OSPF, multicast settings and rendezvous points, syslog, SNMP, alert settings, webhook servers and payload templates, webhook tests, organization-wide alert configs, group policies, client policies and splash authorization, client provisioning, firmware upgrade schedules and rollbacks, staged switch upgrades, floor plans and their device assignments, AP auto locate jobs, management interfaces, switch port cycling, license assignments and moves, co-term license moves, config templates and their switch profile ports, binding networks to templates, network groups, moving networks to another organization, combining and splitting networks, packet captures and their schedules, migrations to a wireless controller, cellular data profiles, MG SIM, band mask, geolocation, LAN, port forwarding, uplink, DHCP, connectivity monitoring and subnet pool settings, eSIM status, service provider accounts and profile swaps, campus gateway clusters, their provisioning, tunnel encryption and SSID mDNS settings, Insight monitored media servers, cloning organizations, claiming devices into and releasing them from inventory, claiming, removing and swapping devices, action batches, and generating and revoking API keys. ENDPOINTS.md lists them all, and Differences from the real API has the rules and defaults for each area.

• Bodies are checked against the request schemas in the official spec: types, enums, required fields and ranges. A bad value gets a 400 naming the field, and so does a null list item or a null in place of a required list or object. A null sent for a settings object leaves it as it was. A null for a network's or device's tags, or an admin's tags or network privileges, clears the list, and a null network name or time zone is ignored.
• PUT is a partial update. Fields you leave out keep their values, nested objects merge, and lists replace. A VLAN's or static route's fixedIpAssignments replaces as a whole too, since it's keyed by MAC, so leaving a MAC out removes its reservation.
• Unknown and read-only fields are ignored, so you can GET an object, change it and PUT the whole thing back.
• POST answers 201 with the new object, and DELETE answers 204. Actions use the spec's code instead: a claim or a port cycle answers 200, a removal 204 and a bulk swap 207.
• The checks that matter to real clients are there: VLAN subnets can't overlap and the appliance IP has to be inside the subnet, static routes need a next hop on a local subnet, names and admin emails have to be unique, a PSK SSID needs an 8 to 63 character key, a firmware upgrade has to move to a newer version (older ones go through a rollback), identity PSKs need an SSID in ipsk-without-radius mode and a group policy that exists, a switch port only takes link speeds it lists, a stack takes 2 to 8 switches of one stackable series (MS390 or MS250 here, not MS120 or MS130), and the default firewall rule always stays last.
• An SSID only shows the fields for its current auth mode, IP assignment mode and splash page, the way the real API does. Switching from PSK to 802.1X drops psk and adds the RADIUS settings, and moving out of NAT mode drops dnsRewrite. RADIUS shared secrets are accepted but never sent back.
• Related data follows along. New VLANs join the site-to-site VPN list, the VPN status endpoint reports what you export, renaming a device renames it in the event log, renaming an SSID renames it for its clients, and deleting a network returns its devices to inventory and drops it from admin privileges, network groups and its spokes' VPN hubs, the same as moving it away.
• Devices can be claimed from the organization's inventory. A claimed device is online right away with no clients: a switch gets empty ports and an MX one DHCP uplink. Removing a device returns it to inventory, an AP's clients move to the network's other APs, a switch's wired clients leave with it, and a network that loses its MX drops out of AutoVPN. A swap puts the new device in the old one's place with its name, settings and clients. Network settings stay as they were through all of this.
• A network moved to another organization takes its devices, clients and settings along and leaves AutoVPN. Networks with different product types can be combined into one, which takes each product's devices and settings from the network that had them, and its network-wide settings, time zone and address from the first one listed. Splitting a combined network gives one network per product type, each with that product's devices and a copy of the settings. Warm spare, rendezvous points and camera quality retention and wireless profiles go with their product's network either way. MQTT brokers serve cameras and wireless MQTT alike, so a combined network takes every network's brokers and each camera or wireless part of a split gets a copy. A third-party VPN peer available to the network follows its MX. Moving licenses to another organization moves the devices they're on to its inventory.
• A network bound to a config template reads its settings from the template, so every network bound to it shares them, and its settings writes answer 400. Warm spare (and its redundancy view), multicast rendezvous points, switch link aggregations and the alternate management interface name the network's own devices, so they stay local and can still be changed. With autoBind, its switches take their ports from the template's switch profile for their model, and a profile port change shows on every bound switch. Unbinding with retainConfigs keeps a copy; without it the network starts over from its defaults.
• Each organization has an unclaimed order to claim into inventory. With the default seed, Acme Corporation's is 4C9557446 (an MX250, an MS130-24P, two MR46s and a co-term license for them) and Acme Test Lab's is 4C9750629 (two MR36s). Claimed devices land in inventory, released ones go back to the unclaimed pool and can be claimed again by serial or order.
• With --webhooks, a webhook test really sends its webhook: the alert type's example, with the network's names, rendered through the payload template and POSTed to the URL with the shared secret. Its status goes from enqueued to processing, then delivered on a 2xx, or retrying and finally abandoned after three tries. Each try goes into the organization's webhook log. Without the flag nothing leaves the emulator, and every test and callback is logged as delivered.
• Live tool jobs read the sim when they finish: a MAC table lists the clients on the switch's ports and behind its APs, port status matches getDeviceSwitchPortsStatuses, and ping device loses every packet while the device is down. A callback in the request sends the finished job to a URL or HTTP server the same way, and its status shows under callback statuses.
• An action batch runs each action through the same routes as a direct call, with the same checks, so any write above works in a batch: create, update and destroy are a POST, PUT and DELETE on the resource, and any other operation is a POST to resource/operation (/networks/{networkId}/bind, /organizations/{organizationId}/networks/combine). A batch applies all of its actions or none: an action that fails puts back the ones before it, and the batch shows failed with the error. Actions the routes can't place, bodies that don't fit the schema and resources in another organization get a 400 before anything runs. An unconfirmed batch is a preview until a PUT sets confirmed. A synchronous batch runs in the request that confirms it, and so does every batch under a frozen --now. createdResources lists the ID and URI each create action returned.
• Every write shows up in getOrganizationConfigurationChanges the way the real change log records API calls: page via API, the method and path as the label, and the object before and after as JSON.

Apart from claiming, removing and swapping devices, and moving or combining networks, writes change configuration, not the simulation. Clients keep their addresses and schedules, traffic stays the same, and a network you create is empty: no devices, clients or traffic. Changing a network's time zone changes what the API reports, not the site's schedule, an SSID outage schedule doesn't take the SSID off the air, cycling a switch port doesn't drop its link, and a reboot changes nothing. Start with --read-only to refuse every write with 405.