Skip to main content

API changelog: User Panel 2.4.2

User Panel API Changelog 2.4.2

Previous Release: 2.4.1 · New Release: 2.4.2

Audience: external integrators with existing User Panel API integrations.

This document covers the User Panel API changes between the 2.4.1 and 2.4.2 releases. Please review each section before upgrading.

1. Summary — What Actually Affects You

Change

Who is affected

Action

Team member paging switched to zero-based

Any client that lists team members with a page parameter

Subtract one from your page numbers (Section 2)

user_team[].user omitted from login and profile responses

Clients reading that nested object

Treat it as optional (Section 3)

Team membership enforced on five endpoints

Clients calling team-scoped endpoints with credentials that are not an active member of that team

Handle 403; expect shorter lists (Section 4)

2. Team Member Paging Is Now Zero-Based (BREAKING)

GET /api/team/{team_id}/members now counts pages from zero. The page parameter keeps its name and type — only the meaning of the value changed.

Before (2.4.1):

GET /api/team/{team_id}/members?page=1&itemsPerPage=50 → members 1–50

After (2.4.2):

GET /api/team/{team_id}/members?page=0&itemsPerPage=50 → members 1–50 GET /api/team/{team_id}/members?page=1&itemsPerPage=50 → members 51–100

This fails silently. If you keep sending page=1, the API returns HTTP 200 with an empty list whenever the team has 50 members or fewer.

There is no error, no warning and no change in status code — the response is indistinguishable from a team with no members. Nothing in your logs will indicate a problem.

Migration: subtract one from every page number you send to this endpoint. The first page is page=0.

If you only ever fetch the first page — for example to display or count members — you can switch to page=0 immediately, before upgrading. page=0 returns the first page on both 2.4.1 and 2.4.2, so the change can be deployed independently of the platform upgrade.

If you iterate through pages, apply the shift at the moment of upgrade: the two numbering schemes do not overlap beyond the first page.

3. Nested user Object No Longer Returned by Login and Profile (BREAKING)

In the responses of POST /api/login and GET /api/user/profile, each entry of user_team[] previously carried a user key. That key is now omitted from these two endpoints.

Before (2.4.1):

"user_team": [ { "team_id": "...", "role_id": "...", "user": {} } ]

After (2.4.2):

"user_team": [ { "team_id": "...", "role_id": "..." } ]

No data was lost. On these two endpoints the nested object was never populated — it was always returned as an empty object. The change is that the key is now absent rather than empty.

Who breaks: clients that read user_team[].user.<field> without checking that user exists. In a strictly typed client this becomes a null-reference error; in a loosely typed one it silently yields undefined.

Migration: treat user_team[].user as an optional field. Where the nested user is genuinely needed, use the team members listing — the object is still populated there.

4. Team Membership Is Now Enforced (BREAKING)

Five endpoints now verify that the caller holds an active membership in the team being queried. There are two different outcomes depending on the endpoint.

Access refused — 403 where 200 was returned:

Endpoint

New behaviour

GET /api/gpuaas/connection-info

Connection details are returned only to members of the team that owns the pool.

GET /api/policy/{policy_type}/team/{team_id}/objects

Policy assignments are returned only to members of that team.

Results filtered — still 200, but fewer rows:

Endpoint

New behaviour

GET /api/workspace

Workspaces are listed only for teams where your membership is active. Removed or expired memberships no longer contribute rows.

GET /api/gpuaas/compatible-instances/{team_id}

Same.

GET /api/team/{team_id}/members

Membership visibility is now limited to teams you are an active member of, or hold a pending invitation to.

Migration: ensure the credentials your integration uses hold an active membership in every team it queries. Add handling for 403 on the first two endpoints. If your integration previously received rows for teams it is no longer active in, expect those rows to disappear.

5. New Endpoints

Method

Path

Purpose

GET

/api/ui-config

Front-end configuration surface.

No endpoint was removed in this release.

6. Non-Breaking Improvements

  • GET /api/user/profile now returns role (a single effective role), user_team (per-team roles) and is_full_administrator. Purely additive — existing fields are unchanged.

  • used_size_in_gb in shared-volume listings is now documented as a decimal rather than an integer. If you are upgrading from 2.4.1 this is not a behavioural change — that release already returned decimal values. Integrators coming from 2.4.0 should parse the field as a floating-point number.

7. Migration Checklist

Subtract one from every page number sent to the team members endpoint; confirm the first page is requested as page=0 (Section 2).

Search your codebase for reads of user_team[].user and add a presence check (Section 3).

Verify the credentials used by your integration hold an active membership in every team it queries (Section 4).

Add handling for HTTP 403 on the gpuaas connection-info and policy objects endpoints (Section 4).

Re-test any logic that counts or displays team members against a team with fewer members than one page — this is where the paging change hides (Section 2).

Parse used_size_in_gb as a floating-point number if you are upgrading from 2.4.0 (Section 6).