This recipe fits production changes where you already know the RRID of the record and want to perform the update in a controlled way. The flow consists of snapshot, change, verification, and rollback.

Prerequisites

• an API key with access to the DNS endpoints
• the rrid of the record you want to change
• a clearly defined target value, for example a new IP address or new CNAME target
• a place where the previous state can be stored for rollback

Step 1: Read the current state

Before every change, read the existing record and persist the current content. This snapshot is the basis for both verification and rollback.

curl --request GET \
  --url 'https://api.regfish.com/dns/rr/4711' \
  --header 'x-api-key: YOUR_API_KEY'

A typical snapshot looks like this:

{
  "success": true,
  "response": {
    "id": 4711,
    "type": "A",
    "name": "api.example.com.",
    "data": "203.0.113.10"
  }
}

Step 2: Apply the planned change

Once the original state has been captured, apply the update by RRID. This is more precise than automatic resolution by name and type.

curl --request PATCH \
  --url 'https://api.regfish.com/dns/rr/4711' \
  --header 'content-type: application/json' \
  --header 'x-api-key: YOUR_API_KEY' \
  --data '
{
  "type": "A",
  "name": "api",
  "data": "203.0.113.20",
  "ttl": 300,
  "annotation": "change-ticket-2026-03-17"
}
'

Step 3: Verify the result immediately

After the update, read the record again. That lets you confirm right away that the intended target value was written and that you touched the expected RRID.

curl --request GET \
  --url 'https://api.regfish.com/dns/rr/4711' \
  --header 'x-api-key: YOUR_API_KEY'

Check in particular:

• that id stayed the same
• that data matches the intended target value
• that ttl and optional annotations were written as expected

Step 4: Roll back if necessary

If the new value is wrong or causes a follow-up issue, restore the previous state with the same fields.

curl --request PATCH \
  --url 'https://api.regfish.com/dns/rr/4711' \
  --header 'content-type: application/json' \
  --header 'x-api-key: YOUR_API_KEY' \
  --data '
{
  "type": "A",
  "name": "api",
  "data": "203.0.113.10",
  "ttl": 300,
  "annotation": "rollback-change-ticket-2026-03-17"
}
'

Alternative: Update through the auto endpoint

If you do not have the RRID stored and exactly one record can be identified by name and type, you can use the auto endpoint instead. For production changes involving multiple similar records, the RRID-based path is more robust.

curl --request PATCH \
  --url 'https://api.regfish.com/dns/rr' \
  --header 'content-type: application/json' \
  --header 'x-api-key: YOUR_API_KEY' \
  --data '
{
  "type": "A",
  "name": "api.example.com.",
  "data": "203.0.113.20"
}
'

Practical notes for production workflows

• capture the full previous state before every change, including type, name, ttl, and data
• use RRIDs in production as soon as multiple similar records might exist
• add annotations with ticket, job, or deployment references
• verify changes immediately after writing them
• prepare the rollback payload before sending the actual update

Result

This workflow treats DNS updates like controlled operational changes rather than single write calls. That reduces risk and makes rollback immediate when something goes wrong.