Promise API
Reference for the domainkit/promise adapter entry point.
Use domainkit/promise at framework actions, route handlers, or other boundaries that want Promises
instead of Effect values.
import { DnsRecord, DomainName, Provisioning } from "domainkit/promise";
const requirement = DnsRecord.Cname.make({
metadata: { ownership: "customer", provenance: "example", purpose: "routing" },
name: DomainName.parse("app.example.com"),
policy: "exclusive",
target: DomainName.parse("tenant.example.net"),
ttl: 300,
});
const result = await Provisioning.create({
provider,
requirements: [requirement],
target: Provisioning.Target.ExactZone({ zone: "example.com" }),
});
VERSION reports the installed package version.
Exported namespaces
| Area | Namespaces |
|---|---|
| Package | VERSION |
| Connections | Connection, AuthorizationLifecycle, ProviderAuth, ProviderAuthorization, ProviderContext, Secret, Diagnostic |
| Discovery | ProviderDiscovery, ZoneDiscovery, Zones |
| DNS values | DnsRecord, DomainName, InvalidInput |
| Provider contracts | DnsProvider, Cloudflare, Vercel |
| Plans | DnsPlan, Provisioning, Deletion |
| Verification | Verification, DnsResolver, DnsResolverPool, DnsOverHttps, CloudflareDnsOverHttps, GoogleDnsOverHttps |
The Promise API accepts Promise-shaped provider and resolver interfaces where appropriate and runs the canonical Effect programs internally. Results, tagged outcomes, plan digests, and failure semantics remain aligned with the core entry point.
Boundary rule
Choose one internal programming model per application layer. Do not repeatedly convert Effect to
Promise and back through the same lifecycle. If the application core uses Effect, keep the canonical
entry point and call Effect.runPromise once at the framework boundary. If the host is Promise-first,
use this entry point consistently.
For browser UI, implement the narrower application transport rather than sending the Promise provider object to the client.