9Login API: windows#
Arrange, show, move and resize the browser windows of running profiles. These commands exist on Windows only.
POST /v1/windows/arrange#
Tile the browser windows of running profiles on a grid, as the Arrange button does. Without ids every running profile is placed, in the order the profile list shows them (its current search and sort), exactly as the button does. With ids only those, one slot each in the order given; a listed profile without a running browser is reported in notRunning and takes no slot. Minimized and maximized windows are brought back to normal first; nothing is raised or focused. arranged gives the rect each window was sent to. A profile started on its own cannot grow past the screen of its fingerprint, so read the windows back with GET /v1/running?window=true when the exact size matters. failed lists unknown ids (notFound), browsers that have not drawn a window yet or run hidden (noWindow), and placements the system refused (failed). The profiles of a Sync control session are arranged all together or not at all, since their windows must keep one size. Positions and sizes are logical pixels: physical pixels divided by the Windows display scale (at 150%, a 1920 pixel wide screen is 1280 wide). The grid starts at the top-left corner of the main monitor and fills the working area of the monitor 9Login is on, unless areaWidth and areaHeight say otherwise. Windows only.
MCP tool: arrange_windows. Access: needs "Allow changes".
| Field | Type | Required | Description |
|---|---|---|---|
ids |
string[] |
no | Profiles to arrange, one slot each in this order. Leave out to arrange every running profile in the order the profile list shows them, as the button does. |
grid |
object |
no | A grid for this call only; nothing is saved. Fields left out come from the grid saved in 9Login (Ctrl+click Arrange). width, height, columns and rows need sizeMode in the same object, with the size of that mode: width and height for "fixed", columns and rows for "grid". |
grid.sizeMode |
string |
no | "fixed": windows of width x height, as many per row as fit. "grid": columns x rows cells that share the area. Values: fixed, grid. |
grid.width |
integer |
no | Fixed mode: window width, logical pixels at scale 0 (another scale resizes it by scale divided by the Windows display scale). Min 1, max 16384. |
grid.height |
integer |
no | Fixed mode: window height, as width. Min 1, max 16384. |
grid.columns |
integer |
no | Fixed mode: windows per row, 0 = as many as fit. Grid mode: columns of the grid, 1 or more. Min 0, max 50. |
grid.rows |
integer |
no | Grid mode: rows of the grid. Min 1, max 50. |
grid.areaWidth |
integer |
no | Width of the area to fill, logical pixels. 0 = the working area of the monitor 9Login is on. Min 0, max 32767. |
grid.areaHeight |
integer |
no | Height of the area to fill, logical pixels. 0 = the working area. Min 0, max 32767. |
grid.shiftX |
integer |
no | With more windows than cells, each extra layer moves right by this much so the windows below stay reachable. Logical pixels, 0 = stack exactly. Min 0, max 32767. |
grid.shiftY |
integer |
no | The same, downward. Min 0, max 32767. |
grid.scale |
number |
no | Zoom of the windows: smaller fits more on the screen. 0 = the Windows display scale. Values: 0, 2, 1.5, 1, 0.8, 0.75, 0.6, 0.5, 0.3, 0.25, 0.1. |
Request
Response
{
"ok": true,
"data": {
"arranged": [
{
"id": "a1b2c3",
"slot": 0,
"x": 0,
"y": 0,
"width": 965,
"height": 1040
},
{
"id": "d4e5f6",
"slot": 1,
"x": 954,
"y": 0,
"width": 965,
"height": 1040
}
],
"notRunning": [
"g7h8i9"
],
"failed": [],
"layout": {
"sizeMode": "grid",
"columns": 2,
"rows": 1,
"tile": {
"width": 965,
"height": 1040
},
"area": {
"width": 1920,
"height": 1040
},
"scale": 1
}
}
}
POST /v1/windows/focus#
Bring the browser window of one running profile to the front, as Show window in its row menu does. A minimized window is restored, raised and given a short shake so it is easy to spot. activated true means the attempt was made: Windows can refuse to move the focus away from the app in front, so the window may stay behind it. Windows only.
MCP tool: focus_window. Access: needs "Allow changes".
| Field | Type | Required | Description |
|---|---|---|---|
id |
string |
yes | Profile id. |
Request
POST /v1/windows/bounds#
Read, move or resize the browser window of one running profile. With none of x, y, width and height it only reads. With any of them it places the window, and the ones left out keep their current value. The answer is the window read back afterwards, which can differ from the request: a profile started on its own cannot grow past the screen of its fingerprint. changed says whether the call moved, resized or restored the window. A minimized window has no usable position, so pass all four. A profile in a Sync control session can be moved but not resized. When the browser has several windows, such as a popup or DevTools, the call acts on the frontmost one. Positions and sizes are logical pixels: physical pixels divided by the Windows display scale (at 150%, a 1920 pixel wide screen is 1280 wide). x and y count from the top-left corner of the main monitor. GET /v1/running?window=true reads every window at once with read access only. Windows only.
MCP tool: window_bounds. Access: needs "Allow changes".
| Field | Type | Required | Description |
|---|---|---|---|
id |
string |
yes | Profile id. |
x |
integer |
no | Left edge. Negative on a monitor left of the main one. Min -32768, max 32767. |
y |
integer |
no | Top edge. Negative on a monitor above the main one. Min -32768, max 32767. |
width |
integer |
no | Window width. Min 1, max 32767. |
height |
integer |
no | Window height. Min 1, max 32767. |
restore |
boolean |
no | Bring a minimized or maximized window back to normal first, so the new position applies. Only with x, y, width or height. Default true. |