POST/organizations
Create an organization
Operation organizations.create
Description
Provisions an additional organization for the signed-in user, who becomes its founding administrator: reserved Admins and Members groups, root container, signed policies, and metadata documents in one transaction. It also creates the replacement for the caller's purged personal organization, which must use a fresh organization id.
Authentication
Requires a signed-in session: the client sends its session token as a bearer token in the Authorization header.
Request body
application/jsonCreateOrganizationRequest
Every signed artifact of a new organization, signed with the caller's existing identity: the same set registration provisions.
17 fields
organizationIdstringrequired- lowercase UUID v4
rootContainerIdstringrequired- lowercase UUID v4
userIdstringrequired- lowercase UUID v4
Identity-signed authorization for the new organization to replace a purged personal organization.
nativeSubscriptionRestorebooleanoptional- always
true
Marks the new organization as the destination of a native store subscription restore.
- always
finalizeReplacementbooleanoptionalCompletes an earlier replacement after the client reset its local copy, moving the user's default organization to it.
replacesOrganizationIdstringoptional- lowercase UUID v4
Purged personal organization this one replaces; accepted only after that purge completed.
Other fields are allowed.
Responses
200 OK
application/jsonCreateOrganizationResponse
Acknowledges a new organization by the ids and hashes of what it created.
19 fields
committedCoreMetadataUpdateIdslist of stringrequired- each item: lowercase UUID v4
Ids of the seeded metadata updates the server committed.
committedProfileUpdateIdslist of stringrequired- each item: lowercase UUID v4
Ids of the seeded profile updates the server committed.
organizationIdstringrequiredorganizationMetadataContainerIdstringrequiredorganizationProfileDocumentIdstringoptionalrootContainerIdstringrequiredrootMetadataAccessEpochnumberrequiredAccess epoch of the root container's metadata document.
rootMetadataAccessStateHashstringrequired- not empty
Access state hash of the root container's metadata document.
rootMetadataDocumentIdstringrequiredrosterProfileContainerIdstringoptionalrosterProfileDocumentIdstringoptionaluserIdstringrequiredFor a replacement, the identity-signed authorization clients verify before following it.
Other fields are allowed.
Other responses
| Status | Meaning | Body |
|---|---|---|
| 400 | Bad Request |
|
| 401 | Unauthorized |
|
| 403 | Forbidden |
|
| 404 | Not Found |
|
| 409 | Conflict |
|
| 500 | Internal Server Error |
|
| 503 | Service Unavailable |
|
Additional rules
The server also enforces these rules, which the schema above cannot express.
inlineRekeyCommitIdmust be present exactly whencontainerRekeysis non-empty.authorizingContainerPathRefsis required whenoutgoingUpdatesis non-empty.containerRekeysmay be non-empty only whenoutgoingUpdatesis non-empty.Outgoing update ids must be unique within the request.
A request carrying
pullCursormust not contain outgoing updates, container rekeys, a content-key bundle, or authorizing paths.historyMode"raw" must not be combined with outgoing updates, container rekeys, a content-key bundle, or authorizing paths.historyMode"raw" requireslocalVersionVectorto be null so the complete retained history is requested.checkpointKind,checkpointPayloadKind, andsourceVersionVectormust be absent together or form a rotation baseline.Each provisioned system-container metadata seed must contain exactly one outgoing update and no container rekeys.
Each provisioned document seed must contain exactly one outgoing update and no container rekeys.
Core and profile metadata update id arrays contain no duplicates.
A container response keyring is null exactly for container key epoch 1.