Client Onboarding

scripts/onboard_client.py drives the same public API endpoints an operator would call by hand (Tenants, Integrations) — deliberately no direct database access, so RLS, RBAC, validation, and audit logging all apply exactly as they would in normal API use. It’s idempotent: an existing tenant slug or domain is reported and reused, never duplicated, so a partial failure is safe to re-run.

Usage

export SEO_OPERATOR_PASSWORD=...   # never pass this as an argument

uv run python scripts/onboard_client.py \
  --api-url https://api.mael.in \
  --email operator@agency.example \
  --tenant-slug dr-chandril-chugh \
  --tenant-name "Dr Chandril Chugh" \
  --domain drchandrilchugh.example \
  --display-name "Dr Chandril Chugh — Neurology" \
  --plan starter \
  --timezone Asia/Kolkata

Flag	Required	Default	Notes
`--api-url`	Yes	—	Base URL of the running API
`--email`	Yes	—	Operator (`super_admin`) email
`--tenant-slug`	Yes	—	URL-safe unique identifier
`--tenant-name`	Yes	—	Display name
`--domain`	Yes	—	e.g. `example.com`
`--display-name`	Yes	—	Domain’s display name
`--plan`	No	`starter`	Plan tier
`--timezone`	No	`UTC`	IANA timezone
`--language`	No	`en`
`--cms-base-url`	No	—	Self-hosted WordPress base URL, if known upfront
`--country-code`	No	—
`--dry-run`	No	off	Print what would happen without making changes

The SEO_OPERATOR_PASSWORD environment variable — never a command-line argument — authenticates the operator account before any tenant call.

What it prints

After provisioning, the script prints the remaining integration checklist for that tenant: which OAuth flows still need running, whether a WordPress application password is needed, and the direct dashboard link to the new tenant.

Get Started

Architecture

Deployment

SDK

CLI

Guides

Examples

Resources

Client Onboarding

Usage

What it prints

Full onboarding checklist

​Usage

​What it prints

Full onboarding checklist

Usage

What it prints