Products

Problem

You want a product served on a DNS domain you register on it — example.com, or a label you have delegated such as app.example.com — instead of leaving the domain unregistered.

Adding and removing a domain requires the product owner or admin role. Any product member can list domains and view their hosts.

Register the domain and publish its records

1. Register the domain on the product. Once registered, the domain belongs to that product and is available to everything running in it.
2. Read the DNS records the platform renders for it. In external mode — the mode every new domain starts in — they are copy-paste setup instructions.
3. Publish those records at your own DNS provider. The platform never touches your zone.
4. Check each host’s state — pending, active, or failed with a reason. The platform does not poll DNS to work this out: in external mode the state is reported by whatever is serving the host.

App. The product’s domain settings.

MCP. Ask your agent: “Add example.com to this product.” It calls organization_domains_add and returns the records to publish. organization_domains_get reads back one domain and its hosts, organization_domains_list reads them all, and organization_domains_remove removes one. Despite the organization_ prefix, all four operate on a product and require a product ID.

REST.

curl -X POST https://api.lessly.com/governance/api/v1/products/$PRODUCT_ID/domains \
  -H "Authorization: Bearer $LESSLY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"domain": "example.com"}'

The response carries the domain’s id, domain, mode, productId, createdAt, createdBy and providerConnectorId. GET, GET …/:domainId and DELETE …/:domainId on the same path list, read and remove — all four are on the Organization API page.

Domains are product-owned

Domains are not owned by your organization and they are not shared between products: adding example.com to one product does nothing for another product, even in the same organization.

A domain registration is an assertion, not proof

• Uniqueness is per product — the pair (product, domain). Two different products may each register example.com, and neither registration blocks the other. The same domain cannot be added twice inside one product.
• There is no verification. No status field, no verified-at timestamp, no ownership challenge of any kind. A product may register a domain it does not control, and nothing will object.

That is safe because registration on its own grants nothing. It produces DNS instructions, and instructions only do something once the records are published in the zone — which requires control of the domain. A domain you do not control never resolves to your product, and the registration exposes no platform resource.

Hosts

A registered domain is a namespace; the individual names served under it are hosts. A host is one FQDN under the domain — the apex example.com, a subdomain app.example.com, or a record name such as _dmarc.example.com — together with the DNS records that host needs.

A host can be claimed once per product. Claiming a host that is already in use fails with a conflict that names the current user of the host, so you can see what to release first.

Removing a domain is blocked while any of its hosts is active: the request fails, names the current users, and removes nothing. Once no active host remains, removal succeeds and any pending or failed hosts go with it.

DNS records

Records are instructions. The platform stores them as given and does not resolve or validate them.

Do not use ALIAS or ANAME. They are provider-side pseudo-records, not real DNS record types, and they are meaningless as instructions. For an apex that needs CNAME-like behaviour, use flattened A records, or publish no records here and manage the alias at your provider. Keep to real record types: A, CNAME and TXT.

External mode and managed mode

Every domain is in one of two modes. A new domain starts in external.

Switching modes

Setting the mode is an explicit action for the product owner or admin: enabling managed mode means picking which connected Cloudflare account to use; disabling puts the domain back into external mode.

Managed mode requires a Cloudflare connection on your organization, attached to the product — see the integrations section. One organization can hold several Cloudflare accounts, and each managed domain is linked to exactly one of them.

The apex must already exist as a zone in that Cloudflare account. The platform does not create zones and does not migrate nameservers. If the zone is not there, the affected hosts are marked failed with a message saying the domain was not found in the connected account.

Switching back to external is non-destructive. The records the platform wrote into Cloudflare are left in place; they are not deleted. Your domain keeps working, and removing those records is up to you.

What the platform will not overwrite

In managed mode the platform only manages records it created or deliberately adopted, and it marks its own records so it can tell them apart. Records under a name it has no host for are never touched, and records belonging to another domain or another product in a shared zone are never touched.

Where an existing record collides with one the platform needs, it is conservative: a single existing address record is adopted and pointed at the platform edge, but several conflicting records are left alone and the host is marked failed instead. The platform never deletes DNS records it did not create in order to make room for its own.

Next steps

• Connect a Cloudflare account: what a connection is and who may create one.
• Create a product: domains are registered per product, never shared between them.
• Add a domain from an agent: the tool’s arguments and what it returns.