Text version. The interactive version, with live examples, is at https://app.proptonomy.ai/docs/white-label. This page as Markdown: https://app.proptonomy.ai/docs/white-label.md. Index of all pages: https://app.proptonomy.ai/llms.txt.

White-label setup and custom domains

Preparing a provider or organization workspace, DNS, branding, sign-in and API access during the controlled rollout.

https://app.proptonomy.ai/docs/white-label

Availability

Choose the workspace owner

• SaaS provider: A provider serves its own customers with its brand and a small Powered by Proptonomy attribution. Each customer separately approves its connection and permissions.
• Your organization: An ordinary organization can use its own domain and branding without becoming a provider. An actual organization Admin manages setup.
• Customer switching: A provider's brand stays attached to its hostname when the selected customer changes. Branding never grants access to customer data.

Set up a provider

1. Agree the integration with Proptonomy Choose a hosted workspace, your own frontend using approved APIs, or a future embedded experience. Agree customer references, allowed actions, support ownership and the API/SSO contract before connecting customers.
2. Proptonomy creates the paused provider and reviews its staff A Proptonomy global administrator assigns a reviewed native account as provider Admin. Support can inspect domain and branding settings but cannot change them. Provider enablement is a separate Proptonomy control.
3. Connect each customer with separate approval A provider Admin creates a setup link for the exact customer reference and supported permissions. The customer's Admin signs in, selects or creates its organization and approves. A provider Admin then reviews and confirms the mapping. Neither step creates staff membership in the customer's organization.
4. Open Manage custom domains in the provider console Configure the provider's domain and brand there. Keep customer permissions and any service credentials separate from domain setup.

Prepare your custom domain

For an ordinary organization, sign in on the Proptonomy app as its Admin and open Organization settings → Manage custom domains. The standalone domain page also allows an inactive organization's Admin to recover its existing domains; creating, preparing or enabling new access requires an active organization.

1. Register the exact hostname, paused Enter a hostname such as workspace.company.example, without https, paths, ports or wildcards. This is an example, not a configured address. Registration alone does not create a live site.
2. Open your DNS provider and copy the records Open the DNS provider shortcut on your domain setup screen, sign in and select your domain. Add the TXT and CNAME records using the copy buttons. Leave TTL on Auto or its default. If the provider appends your domain to Name/Host, enter only the prefix so the full name matches the one shown. With Cloudflare DNS, set the workspace CNAME to DNS only (gray cloud). Keep the ownership TXT in place and check its deadline.
3. Verify ownership and prepare TLS Review the displayed hostname and start verification. Proptonomy checks DNS and prepares the Cloudflare custom hostname. DNS ownership and certificate status are checked separately.
4. Check HTTPS routing, then review access Run the separate routing check. Proptonomy must complete the controlled rollout checks before enabling application traffic. A green certificate or an enabled setting alone does not mean the site is live.

DNS dashboards: Cloudflare (https://dash.cloudflare.com/?to=/:account/:zone/dns/records), GoDaddy (https://dcc.godaddy.com/control/portfolio), Namecheap (https://ap.www.namecheap.com/domains/list/), Squarespace (https://account.squarespace.com/domains) and Route 53 (https://console.aws.amazon.com/route53/). These links open the provider's dashboard; you may need to select your domain. Use the company hosting your DNS, which can differ from your registrar.

You add your DNS records. Proptonomy checks ownership and creates the Cloudflare hostname and certificate request using its configured account. Add any additional certificate records that appear, then check again. You do not need to move DNS or share its password. Platform Cloudflare configuration and production activation are separate Proptonomy setup steps.

Upload your branding

On the same domain page, set your display name, primary colors for light and dark themes, and optional support email or HTTPS support link. Review the saved previews in both themes. Powered by Proptonomy remains visible and cannot be removed in the branding editor.

• Upload a static PNG, JPEG or WebP original up to 10 MiB, 8192 pixels per side and 16 megapixels.
• Resizing and conversion are automatic. Logos keep their proportions; rectangular favicons receive transparent padding to make them square. There is no need to export exact output dimensions first.
• Images are oriented, stripped of metadata and stored as PNG. Detailed images may be reduced further to fit the stored file size. Animated images, SVG and other unsupported formats are refused.
• Your brand appears in the custom-domain header, sidebar mark, tab title and favicon. Canonical account approval stays visibly Proptonomy. Installed mobile apps and PWA install icons are not rebranded by this setup.

Sign in and manage sessions

Once activated, the custom workspace checks its domain before loading account information. Sign-in opens the canonical Proptonomy app, where you review the exact destination and current account before approving.

The single-use handoff lasts two minutes after approval, so time spent signing in does not use that window. Access tokens last fifteen minutes and renew within an eight-hour maximum session. After that, approve a new sign-in.

The account keeps its existing organization memberships and permissions. A provider hostname does not restrict that native account to one customer or turn it into a delegated partner identity. Review and revoke your domain sessions from Sign-in methods on the canonical Proptonomy app.

APIs and embedding

• Provider applications use authorized existing Proptonomy resource APIs. Credentials, customer consent and supported operations are configured separately; a domain does not unlock every API or product module.
• Proptonomy's connection to a provider API uses a credential issued by that provider. Agree who initiates and approves an action, who executes it and how to verify its actual result.
• Machine credentials stay on the server. Direct calls from your frontend need a separately approved browser authentication flow and allowed origins. A DNS record does not register a CORS origin or OAuth redirect.
• Additive API changes stay on major 1. A breaking change requires a new major and an explicit migration. Old majors are retained only while registered or active dependencies still need them.

Pause, recovery and removal

• Pause retains the DNS and external hostname binding while invalidating domain access. An inactive organization's actual Admin can still inspect and recover its registrations.
• After a lost or uncertain response, refresh and inspect the recorded result before trying another write. Keep the same registration request identity; do not create a second claim to bypass recovery.
• For a branding conflict, refresh and compare the newer saved version, then explicitly keep or discard your draft. An uncertain upload or removal holds further writes until a successful refresh.
• Remove retires the local registration first. External cleanup is a separate reviewed operation. Confirm its result before removing DNS records yourself; Proptonomy never removes your DNS records for you.

All documentation pages

• White-label setup and custom domains — Preparing a provider or organization workspace, DNS, branding, sign-in and API access during the controlled rollout.
• Working for a client — How a cleaning or maintenance company receives a client's tasks in its own workspace, and what it sees of the client.
• Roles and what they can do — The six roles, which one to give whom, and a live view of what each role can read and change.
• Inviting people and managing roles — Inviting a coordinator or a cleaner, accepting the invitation, changing a role, and property scopes.
• Receiving and delegating tasks — Where a client's tasks appear, how a coordinator hands one to a cleaner, and what the client sees back.
• The app for cleaners — Inviting staff, installing the iPhone or Android app, signing in, and taking a task from Start work to Finish.
• Location sharing — What the app records about where people are, with whose consent, and what a coordinator sees in the Command Center.
• Working from WhatsApp — One message connects you. What a cleaner can ask and do from WhatsApp, and how coordinators reach their team.
• Languages and translation — The relay that re-posts every group message in each language, your inbox language, translating one message, and the language the AI writes in.
• Setting up the property profile — The field pool, the structure and the Express, Full and Continuation forms; the built-in fields to use instead of custom copies; field options, show-when rules, translations and publishing.
• SOPs and automation triggers — Start SOPs, automatic tasks and messages from events, schedules or webhooks, with typed conditions and assistant chat commands.
• What syncs with each integration — For each PMS, task tool, key service, pricing tool and messaging channel: what Proptonomy reads, what it writes back, how often it syncs, and how to connect it.