A domain is more than its DNS records.

People register a domain because they want to use a name: publish a website, route visitors, prove ownership to a service or keep track of renewal. DNS records are essential, but they are only one layer of that job. IaGenify SDK 0.3.1 expands the domain resource around the tasks people actually perform.

Connect a name to something you host

A hosted project can be attached to the domain root or a specific subdomain. The domain resource then reports its attachments, and detaching a subdomain removes that relationship without asking the developer to reconstruct the underlying record workflow by hand.

const domain = await api.domains.get("example.com");
await domain.attach({ host: site.id });
await domain.attach({ host: endpoint.id, name: "api" });
const connected = await domain.attachments();

This separates intent from plumbing. The application asks to attach `api.example.com` to a host; the platform coordinates the DNS side with the hosting side. A DNS record on its own can point a name somewhere, but it cannot tell the hosting service which project should answer for that name.

Redirects are a different operation

A CNAME is not a browser redirect. A CNAME directs DNS resolution; a redirect sends an HTTP response that moves a visitor to another URL and can preserve the path and query. The SDK now gives redirects their own operations, so a developer can add, list and remove a redirect while choosing the source, destination and status behavior.

await domain.redirects.add({ from: "www", to: "@" });
const rules = await domain.redirects.list();

That distinction matters operationally. Redirect rules only work for traffic that reaches the service applying them, so the domain's routing configuration must meet the platform's requirements. The API surfaces that condition rather than silently changing how a hostname is served.

Understand the domain's state

A domain also has a lifecycle beyond routing. The SDK can read ownership data that a registry publishes, identify domains approaching expiration, inspect TLS status, manage DNSSEC status and create TXT-based service verifications. These operations make the domain resource useful for maintenance as well as setup.

Some facts are available only when a registrar or registry publishes them. In those cases, the result can say that the value is unknown rather than filling the gap with a guess. That lets an application distinguish a confirmed expiry date from information it still needs to obtain.

DNS stays available, with more context around it

Direct DNS record management remains part of the API. The change is that developers no longer have to treat every domain task as a low-level record edit. Attaching a project, configuring a redirect, checking TLS or adding a service verification each has a domain-level operation, while the records remain available when that is the actual task.

A domain is a name people use, a service they connect, and a lifecycle they maintain. DNS is one important part of that picture.

For developers building account dashboards, deployment automation or domain-aware workflows, the expanded resource makes a common operation easier to express and easier to inspect. The domain can be connected to a real service without reducing the whole experience to a list of records.