Automate Your DNS with the RepublicNodes API

If you're managing DNS for infrastructure that changes on its own — a dynamic IP, an autoscaling setup, a CI/CD pipeline that provisions new subdomains — clicking through a dashboard doesn't scale. That's what the DNS Hosting API is for.

Getting your API key

Open your DNS management panel and scroll to the API access section. Generate a key, give it a name (e.g. "CI pipeline" or "DDNS script"), and choose whether it should be read-only or allowed to make changes. The raw key is shown exactly once — copy it immediately, since only its hash is stored afterward.

Each key is scoped to the one zone it was created under — there's no way for a key to reach any other domain, even another one you own, so a leaked key has a strictly limited blast radius.

The endpoints

GET    /api/v1/dns/my/zone
GET    /api/v1/dns/my/records
POST   /api/v1/dns/my/records
PATCH  /api/v1/dns/my/records
DELETE /api/v1/dns/my/records
GET    /api/v1/dns/my/nameserver-status

Authenticate with Authorization: Bearer <your key>. There's no zone ID to look up or pass around — the key itself determines which zone you're operating on.

Example: adding a record

curl -X POST https://republicnodes.com/api/v1/dns/my/records \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "api", "type": "A", "content": "203.0.113.10", "ttl": 300}'

name accepts a bare subdomain like api, a nested one like v1.api, or @ for the zone apex. The response is a plain JSON object with the record you just created.

Example: a simple dynamic DNS updater

A common use case is keeping an A record pointed at a residential or dynamic IP that changes periodically. A minimal cron-driven updater looks like this:

#!/bin/bash
CURRENT_IP=$(curl -s https://api.ipify.org)
curl -X PATCH https://republicnodes.com/api/v1/dns/my/records \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"name\": \"home\", \"type\": \"A\", \"old_content\": \"PREVIOUS_IP\", \"content\": \"$CURRENT_IP\", \"ttl\": 300}"

Run that on a schedule (cron, a systemd timer, whatever you already use) and home.yourdomain.com stays pointed at wherever you actually are.

Checking propagation programmatically

GET /api/v1/dns/my/nameserver-status returns a live, real check of your domain's current public nameservers — handy for a provisioning script that needs to wait until DNS has actually propagated before moving on to the next step, rather than guessing with a fixed sleep.

Full endpoint reference and all supported record types are documented right in your DNS panel's API access section.