Hello Maximiliano,

Your analysis is spot-on. Here is the clarification regarding the current state of the connector and the available options:

1. Is there an official/supported way to enable/disable multiple IP Outputs in a single request?
No, not currently.

• Table 1600 Behavior: Column 1643 (ipoutputsstatus_1643, the write column for State 1603) triggers QAction 9 (Set IP Outputs), which is configured with row="true". Setting this column across multiple rows causes QAction 9 to execute once per row, resulting in one individual HTTP setOutputs request per output.
• QAction 32092 ("Tables Bulk Update"): As you observed, QAction 32092 only handles bulk updates for:
  1. Decoder Services (PID 3782)
  2. IP Output Input Redundancy Settings (PID 30592 / 31092 for table 30500/30600) via SetInputRedundancySettings (currently only implemented for API version 1.31).
     It does not target Table 1600 (IpOutputs) or the Enabled / State property.

2. Can you use the InterApp GenericRequest as a workaround?
Yes, technically this is possible, but there are a few important considerations:

• Execution Flow: An InterApp message with:
  • RequestType = GenericRequest.ReqType.IpGatewayOutputs
  • RequestVerb = GenericRequest.ReqVerb.Post
  • Slot = <slotNumber>
  • RequestData = <raw JSON-RPC request string>

  will be queued in the connector's internal buffer and sent via HTTP Session 430 (POST to RequestHandler.GetUriForBoard(slot)). Once completed, the connector automatically triggers a poll refresh for RequestType.IpGateway_Outputs to update Table 1600.

• Key Constraints:
  1. Per-Slot Scoping: Appear X boards have independent REST/JSON-RPC endpoints (/api/slot/{slot}). Outputs can only be bundled into a single HTTP request if they reside on the same module/slot. Outputs across different slots will still require separate requests per slot.
  2. Schema & Version Matching: The raw JSON-RPC payload must conform to the exact Appear schema version running on that card (e.g. ipgateway:1.31/output/SetOutputs, 1.42, 1.51, or 1.58).
  3. Internal Cache Delay: The connector's in-memory output dictionary is only refreshed after the subsequent GetOutputs polling cycle completes.

3. Is there a plan to support this natively?
Currently, there is no active development task to extend bulk updates to Table 1600.

To implement native support cleanly, the connector would need:

1. A dedicated bulk update parameter (similar to PID 30592) or a context menu / Automation entry point that accepts multiple output keys and desired states.
2. Logic in IpGatewayHelper to group the requested changes by Slot, update the in-memory cache, and dispatch a single SetOutputs JSON-RPC request per slot across all supported API versions (1.31 through 1.58).

If you require this natively in the standard connector, please submit a feature request / improvement collaboration task through the usual Skyline support or product channels. Since you mentioned being able to test on your system, noting that in the request will definitely help speed up verification!