Register Tenant

registerTenant Mutation

Registers a new tenant (organization) in the pyck system along with an initial admin user. This mutation is unauthenticated and can be called without an Authorization header, making it suitable for self-service tenant provisioning.

Arguments

Name	Type	Description
input	RegisterTenantInput!	Input data for registering the tenant and admin user

Return Type

RegisterTenantResponse! - Contains the success status and details of the registration operation.

Input Fields

RegisterTenantInput:

Field	Type	Description
name	String!	Required tenant name
adminUsername	String!	Required username for the initial admin user
adminEmail	String!	Required email address for the initial admin user
adminFirstName	String!	Required first name of the initial admin user
adminLastName	String!	Required last name of the initial admin user
adminPassword	String!	Required password for the initial admin user

Usage Example

mutation {
  registerTenant(
    input: {
      name: "Warehouse North",
      adminUsername: "admin",
      adminEmail: "[email protected]",
      adminFirstName: "Jane",
      adminLastName: "Doe",
      adminPassword: "securePassword123!"
    }
  ) {
    success
  }
}

JavaScript Example

const registerTenantMutation = `
  mutation RegisterTenant($input: RegisterTenantInput!) {
    registerTenant(input: $input) {
      success
    }
  }
`;

const variables = {
  input: {
    name: "Warehouse North",
    adminUsername: "admin",
    adminEmail: "[email protected]",
    adminFirstName: "Jane",
    adminLastName: "Doe",
    adminPassword: "securePassword123!"
  }
};

// Using fetch or your preferred GraphQL client
const response = await fetch('/graphql', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    query: registerTenantMutation,
    variables: variables
  })
});

const result = await response.json();
console.log('Tenant registration result:', result.data.registerTenant);

Current Behavior: Email Alias Handling

When registering multiple tenants, the system allows re-use of the same admin email address. However, the resulting tenant-specific emails are isolated:

Example scenario:

1. Register tenant 1 with [email protected]

   • Creates primary email: [email protected]

   • Adds alias: [email protected]

2. Register tenant 2 with [email protected]

   • Creates primary email: [email protected]

   • Adds alias: [email protected]

Important notes:

• Each tenant gets its own tenant-specific primary email (e.g., [email protected])

• The original email ([email protected]) is added as an alias to both accounts

• Cross-tenant authorization is not supported: [email protected] cannot access tenant 1 resources and vice versa

• Each tenant registration creates a separate, isolated user account

Recommendation: Use unique email addresses for each tenant registration to avoid confusion and ensure clear account separation.

Notes

• This mutation does not require authentication

• The admin user will have full administrative privileges within the new tenant

• Password requirements may apply based on system security policies

• Tenant names should be unique within the system

• This endpoint is not subject to standard tenant isolation rules