create
create(Create a virtual data plane Create a virtual data plane in an organization. The parent organization is identified by therequest:CreateVirtualDataplaneRequest):Promise<CreateVirtualDataplaneResponse>
org_id path parameter alone; the x-hh-org-id header does not participate. Your
organization’s id is listed on the API keys page of your organization settings in the
HoneyHive app.
A virtual data plane is a logical tenant boundary hosted on a physical cluster, and several
of them commonly share one cluster. Workspaces are created inside it.
cluster_id is optional, and omitting it is the common case: the new virtual data plane is
placed on the same cluster as the organization’s existing ones. Two situations require it
explicitly, and both return a 400 that says so rather than guessing: an organization whose
existing virtual data planes span more than one cluster, and an organization that has none
yet. Every response includes cluster_id, so reading an existing virtual data plane tells
you which value to send.
A cluster admits an organization only if your control plane administrator configured it to,
so a cluster_id you can read from a sibling virtual data plane is not necessarily one you
may place a new virtual data plane on. A cluster that does not admit this organization
returns a 403. When you named the cluster, the fix is a configuration change your
administrator makes. When this endpoint inferred the cluster, send an explicit cluster_id
to place the virtual data plane on another cluster.
Deployments differ in who places virtual data planes. Where HoneyHive assigns them to
organizations automatically, this endpoint returns a 403 for every request and the
placement is not yours to make. Deployments whose administrators own the scope tree are
the ones this endpoint serves.
The optional dataplane_creator field names the user (by email) who receives the
dataplane-creator membership on the new virtual data plane. The named user must already be a
member of the organization. When omitted, it is created without any membership. The field is
only accepted on API-key-initiated requests; user-initiated creation always makes the
calling user the creator, so sending the field returns a 400.
The roles that membership carries come from your organization’s role configuration. An
organization that grants no role on dataplane creation is a supported case: the request
still succeeds and the named user receives no access. A 200 response is not by itself
confirmation that the named user was granted anything.
A dataplane_creator who is already signed in does not see the new virtual data plane
immediately. A session captures its scope tree and permission grants when it is created, so
a membership granted afterwards is not reflected in it; the refresh takes effect on their
next request to the control plane.
delete
delete(Delete a virtual data plane Delete a virtual data plane. It is soft-deleted (archived) and no longer appears in reads; the response returns the archived virtual data plane. It is identified by therequest:DeleteVirtualDataplaneRequest):Promise<DeleteVirtualDataplaneResponse>
virtual_dataplane_id path parameter alone; the x-hh-dataplane-id header does not
participate.
Deleting a virtual data plane also archives every workspace inside it and every project
inside those workspaces, so the events, datasets, and evaluations in them are no longer
reachable. Because that reaches two levels below the resource named in the URL, a virtual
data plane with active workspaces is rejected with a 409 unless the request sets
dangerously_delete_child_scopes=true. Workspaces that were already archived do not count.
The response describes only the virtual data plane. It does not enumerate what the cascade
archived, so read that first if you need the list.
This endpoint is unavailable where HoneyHive assigns virtual data planes automatically,
and returns a 403 there.
get
get(Get a virtual data plane Retrieve a single virtual data plane by id. It is identified by therequest:GetVirtualDataplaneRequest):Promise<GetVirtualDataplaneResponse>
virtual_dataplane_id
path parameter alone; the x-hh-dataplane-id header does not participate.
The returned name is the display name. The globally unique slug assigned at creation is
an internal detail and is not part of this contract. cluster_id is the physical cluster
hosting this virtual data plane, and it is the value to send when creating another one
beside it.
Reads work on every deployment, including those where HoneyHive assigns virtual data
planes automatically and the write endpoints are unavailable.
update
update(Update a virtual data plane Update a virtual data plane’s display name. It is identified by therequest:UpdateVirtualDataplaneRequest):Promise<UpdateVirtualDataplaneResponse>
virtual_dataplane_id
path parameter alone; the x-hh-dataplane-id header does not participate.
name is the only field this endpoint changes. cluster_id is placement rather than
description: the workspaces and projects inside a virtual data plane hold data on the
cluster hosting it, so moving one is a migration and not an update. A request that omits
name, or sends the current one, changes nothing.
This endpoint is unavailable where HoneyHive assigns virtual data planes automatically,
and returns a 403 there.