Ingramdomains.ingram.tech
Sign inSign up

Guides

.md

Transfers

Transfer a domain in (standard)

Prerequisites at the current registrar: unlock the domain and obtain its EPP/auth code.

curl -s https://domains.ingram.tech/api/v1/domains/example.com/transfer \
  -H "authorization: Bearer $INGRAM_TOKEN" \
  -H 'content-type: application/json' \
  -H 'idempotency-key: 1b9d6e30-transfer-1' \
  -d '{"auth_code": "ABC-123-XYZ", "confirm_price": 15}'
  • Priced per the TLD's transfer fee (GET /api/v1/tlds); requires confirm_price and debits the wallet.
  • Most registries include a +1 year renewal in a transfer.
  • Registry processing typically takes 5–7 days (the losing registrar can release early). The response's registry status will be Pending — the domain appears in your portfolio immediately and activates when the registry completes.
  • DNS carries over — see Keeping DNS working below. By default, DNS hosted by the losing registrar moves to Ingram DNS with its records copied, and independent DNS (Cloudflare, Route 53, …) is kept as it is.

In the dashboard: Domains → Transfer in. It quotes first, then asks you to confirm at that exact price. Before you confirm, it shows where each domain's DNS will go and which records will come across.

Keeping DNS working

Where a domain's DNS is hosted decides what a transfer does to it:

  • Independent DNS (Cloudflare, Route 53, Google Cloud DNS, …) is unaffected by a registrar change. The transfer keeps those nameservers, and nothing changes for visitors or email.
  • DNS run by the losing registrar (GoDaddy's domaincontrol.com, OVHcloud, Namecheap, Gandi, IONOS, another Netim account, …) is usually deleted by that registrar once the domain leaves. Sometimes this happens at once, sometimes days later. Keeping those nameservers would keep a delegation to a zone that is about to disappear. So by default the domain moves to Ingram DNS and its records are copied into the new zone.

Whatever you choose, the records are read and saved on the domain before the transfer is submitted. When the domain moves to Ingram DNS, it arrives on its old nameservers. Once it lands in your account (we check every ten minutes, so you don't need to watch), we switch it to Ingram DNS and write the records in the same step, so nobody is ever served an empty zone. The copy is kept afterwards, and you can download it from the domain's DNS tab.

What a copy can and can't include:

  • DNS can't be listed from outside (zone transfers are almost always refused), so the records are found by asking the old nameservers about the names a zone usually has: the root, a list of common hostnames, DMARC and the DKIM selectors of common mail providers, common SRV services, every subdomain in the domain's public certificate history, and a wildcard. A record under a name nobody checked won't come across. If you use other subdomains, export a zone file from your current provider before transferring. You can import it later from the DNS tab (Import zone file) or with POST /api/v1/domains/{name}/zone/import.
  • Record types we don't host (for example HTTPS, ALIAS) are listed as not copied, with the reason.
  • Records that point at the old registrar's URL or mail forwarding service are copied but flagged, because they stop working once the domain leaves.
  • DNSSEC: if DNSSEC is on at the old provider, turn it off there before the transfer. Otherwise the domain stops resolving when its DNS moves.

On the API, choose with dns on the transfer (auto is the default, keep, or ingram) or pass nameservers to use your own. The response's dns object says what happened: nameservers (kept / ingram / custom), provider, recordsSaved, copyRecords, and warnings (registrar_dns_kept, dnssec_active, old_dns_unreachable, partial_copy). GET /api/v1/domains/{name}/zone/saved returns the saved records and, once they've been written, what was imported, skipped or failed and why.

Internal transfers (already at our backend)

Our registrar backend is Netim. A domain already registered through Netim (any Netim account) cannot go through a registry transfer — instead it moves with an internal transfer, which is:

  • Free — no registry operation happens, nothing is charged.
  • Fast — with a valid auth code the account move executes automatically, typically in minutes.
  • Non-renewing — the expiry date does not change. Renew separately if the domain is close to expiry.
  • DNS-preserving: the same rules as above apply. A domain on another Netim account's DNS moves to Ingram DNS with its records copied (that zone stays behind in the other account), and independent DNS is kept and re-applied right after the move. If the current nameservers can't be read at that moment, the move is refused rather than risked; retry shortly.

In the dashboard, Transfer in takes one domain or several separated by commas — a batch shares the registrar and owner, each domain gets its own transfer code, and the button carries the total. It asks for the current registrar — the company you pay for the domain — from a list of common ones (Netim among them). The choice is prefilled when the lookup recognises the registrar (RDAP, with a WHOIS fallback for TLDs such as .eu that have no RDAP service), and it drives the rest of the form: picking Netim switches to the free internal path, any other registrar shows where that registrar keeps the transfer code. Without an auth code, confirmation emails go to both accounts instead of executing immediately.

The admin, technical and billing roles are set to your workspace's default contact; you can point them at another contact from the domain's Contacts tab. The registrant/holder is not changed by the internal transfer itself — see the next section for how to change it as part of the move.

Changing the registrant

The registrant is the domain's legal holder. Changing it is a registry trade, not a contact edit, so it is its own operation with its own price: the TLD's trade fee from GET /api/v1/tlds, which is 0 on most TLDs (.eu, .be, .com, …) and a real fee on a few ccTLDs. The admin, technical and billing contacts are untouched. Per-TLD rules apply afterwards: some registries email the new holder to approve the change, and most gTLDs apply the ICANN 60-day change-of-registrant lock on outbound transfers.

In the dashboard there are two ways in:

  • On a domain you hold: Domain → Contacts → Change registrant. The dialog quotes the fee, names the consequence, and confirms at that price.
  • While transferring in: the Transfer in dialog has a registrant picker. A standard registry transfer lands under that contact directly. An internal transfer keeps the current holder unless you tick Change the registrant once it arrives, in which case the change is queued and runs the first time the domain page loads after the move — at the fee shown when you queued it. If it can't run (a fee moved, the balance is short), the domain page says so and offers a one-click retry or lets you keep the current holder.

The registrant change is not yet on REST, MCP or the CLI — those surfaces have no contact book yet, so there is nothing to name the new holder with. That lands together with contacts on the public surfaces.

Transfer a domain out

Request the auth code and hand it to the gaining registrar:

curl -s -X POST https://domains.ingram.tech/api/v1/domains/example.com/auth-code \
  -H "authorization: Bearer $INGRAM_TOKEN"

The code is emailed to the registrant contact. Registrar lock must be off for the gaining registrar's transfer to succeed — toggle it via PATCH /api/v1/domains/{name}/settings, the domain's Security tab, or the Transfer out card on the Advanced tab, which stays closed until you unlock and offers a one-click re-lock. Unlocked domains are flagged in the portfolio list because an unlocked domain plus a leaked auth code is a hijack.

Payments & the walletDNS & nameservers