DomainsDocsSign in
Guides

Presets and imports

Presets add a provider's records in one call. Imports copy a domain's records from its current DNS host before you move it.

Presets

idAddsParams
googleGoogle Workspace: MX smtp.google.com, SPF, DKIM (you paste the value from Google) and a starter DMARC—
zohoZoho Mail: three MX, SPF, DKIM (pasted from Zoho) and a starter DMARC—
vercelAn apex A record (76.76.21.21) and a www CNAME to cname.vercel-dns.com—
coolifyApex and wildcard (*) A records to your server, TTL 5 minutesserver_ip
sendbyteSendByte SPF, DKIM CNAME and DMARC, each pasted from your SendByte domain settings—

Always preview first: it lists every row and what would happen to it, and changes nothing. Then apply with the same body.

const preview = await itoka.presets.preview('ojaara.com', 'coolify', { params: { server_ip: '192.0.2.10' } });
console.log(preview.summary.text); // "2 to add · 1 to replace … Nothing changes until you apply."

for (const row of preview.rows) console.log(row.status, row.type, row.name, row.label);

const applied = await itoka.presets.apply('ojaara.com', 'coolify', { params: { server_ip: '192.0.2.10' } });
console.log(applied.applied.text); // "Applied just now: 2 added, 1 replaced. Live on ns1 and ns2."

Rows

statusMeans
addWill be added.
presentAlready there.
coveredAlready covered (for example by your SPF record).
conflictSomething else is at that name. Choose replace, keep or merge (SPF) under resolutions.
needs_valuePaste a value from the provider (a DKIM key) under values, by the row’s key. Skipped until then.
invalidThe value you gave isn’t valid; problem says why.
PresetRequest
{
  "params": { "server_ip": "192.0.2.10" },
  "values": { "TXT|google._domainkey|2": "v=DKIM1; k=rsa; p=MIIBIjAN…" },
  "resolutions": { "MX|@": "replace" }
}

Take the keys from the preview: values uses a row's key, and resolutions its resolution_key (rows that share one, like all the MX records at a name, are settled together).

GET /zones/{zone}/setup returns checklists for providers whose records the zone already has, with which steps are done.

Imports

Before switching nameservers, copy the domain's records so nothing stops working. Two ways to read them, then one call to copy the rows you pick:

  • POST /zones/{zone}/import/scan reads them from the domain's current nameservers: a zone transfer if allowed, otherwise about 100 common names (www, mail, DKIM selectors, DMARC…). Takes up to 45 seconds; names nobody guesses aren't found.
  • POST /zones/{zone}/import/zonefile with {text}: a BIND zone file, as cPanel and most hosts export it (up to 512 KB and 1000 records).
  • POST /zones/{zone}/import/apply with the rows to copy (up to 500).
const found = await itoka.imports.scan('ojaara.com');
console.log(found.summary); // "8 of 11 records aren't in Itoka yet; 1 already is; 2 can't be copied."
const result = await itoka.imports.apply('ojaara.com', found); // the rows it picked
console.log(result.text);

Each row has a status: new (picked), differs (an A, AAAA or MX beside others; not picked), present, conflict, invalid, unsupported or managed (the old host's NS, not needed). Rows are checked again when you apply; ones that no longer fit are skipped and listed. All import endpoints need records:write.

PreviousFree subdomains