Team

A team is the tenant an API key acts for. A key is pinned to exactly one, so both endpoints here are singletons addressed without an id — there is no other team a key could name, and no path parameter that could disambiguate one.

Requires team:read, which is not in a key's default ability set. The team resource and its roster carry member names and email addresses — personal data a minimally-scoped key has no business reading — so the ability is granted deliberately rather than by default. A key that has been calling GET /v1/me since v1 shipped does not already hold it.

This surface is deliberately narrow: identity only. Billing, plan state, the owner's contact details and the invitation flow stay out of v1, and membership changes happen in the Synex application rather than here. Treat it as a way to label data you already have, not as an administrative surface.

The team model

Name
object
Type
string
Description
Always team.
Name
id
Type
integer
Description
The team's numeric identifier.
Name
name
Type
string
Description
The team's display name.
Name
created_at
Type
string
Description
ISO 8601 timestamp of creation.

The team member model

Name
object
Type
string
Description
Always team.member.
Name
id
Type
integer
Description
The user's numeric identifier. This is the value GET /v1/audit_events reports as user.id and accepts in its user filter.
Name
name
Type
string
Description
The member's name.
Name
email
Type
string
Description
The member's email address.
Name
role
Type
string
Description
owner, admin, editor or viewer.
Name
joined_at
Type
string
Description
When they joined. Null for the owner, who reaches the team through the team record itself rather than through a membership row.

GET/v1/team

Retrieve the team

The team the calling key acts for. Requires team:read.

This is also where you read a key's team — the API key object deliberately carries no team field, because there is only ever one answer.

Request

GET

/v1/team

curl https://api.synexcloud.com/v1/team \
  -H "Authorization: Bearer $SYNEX_API_KEY"

Response

{
  "object": "team",
  "id": 42,
  "name": "Kestrel Energy",
  "created_at": "2026-01-14T09:22:10Z"
}

GET/v1/team/members

List team members

Everyone on the team, ordered by ascending user id. Requires team:read.

Unpaginated by construction. A team is a handful of people, not a collection, so this endpoint accepts no limit and no cursor and returns every member in one response. It still uses the standard list envelope so a client's generic list handling works unchanged: has_more is always false and next_cursor always null, which means a normal paging loop terminates after one pass rather than needing a special case.

The roster includes the owner, whose joined_at is null rather than a timestamp. role is owner for that person and the membership role for everyone else.

The practical use is joining names to history: id is the value the audit log reports as user.id and accepts in its user filter, so this endpoint is how an audit entry becomes a person, and how you turn a name back into a filter.

Request

GET

/v1/team/members

curl https://api.synexcloud.com/v1/team/members \
  -H "Authorization: Bearer $SYNEX_API_KEY"

Response

{
  "object": "list",
  "data": [
    {
      "object": "team.member",
      "id": 7,
      "name": "Marta Ilves",
      "email": "marta@kestrel-energy.example",
      "role": "owner",
      "joined_at": null
    },
    {
      "object": "team.member",
      "id": 118,
      "name": "Jane Ops",
      "email": "jane@kestrel-energy.example",
      "role": "admin",
      "joined_at": "2026-02-03T11:47:22Z"
    }
  ],
  "has_more": false,
  "next_cursor": null,
  "url": "/v1/team/members"
}