WhoisFreaks API Migration Guide: Upgrading from v1.0 to v2.0

Published: November 14, 2025
Last Updated: Nov 27, 2025

This guide explains:

  • What changed in v2.0
  • What new fields were added
  • When existing integrations might break
  • How to upgrade safely

1. Endpoint changes

Old (v1.0):

GET https://api.whoisfreaks.com/v1.0/whois apiKey=API_KEY&whois=live&domainName=example.com

New (v2.0):

GET https://api.whoisfreaks.com/v2.0/whois/live?format=json&domainName=example.com&apiKey=API_KEY

What this means:

  • The base path changes from /v1.0/whois to /v2.0/whois/live.
  • Query parameters stay basically the same only whois=live has been adjusted to the base path.
    (apiKey, domainName, optional format=json).

Everything you already used in v1 still works the same way in v2 (same parameters, same HTTP method). The following is a detailed overview of newly added fields in the API response.

{
  //older fields remain the same
  
  "secure_dns": "...",       // NEW Field
  "domain_handle": "...",    // NEW Field
  "abuse_contact": {         // NEW Object
      "iana_id": "",                         
      "registrar_name": "",
      "whois_server": "",
      "website_url": "",
      "email_address": "",
      "phone_number": ""
  },
  "eligibility_info": {      // NEW Object
      "id": "",
      "name": "",
      "type": ""
  }
  
  "domain_registrar": {
      // older fields remain the same
      "id": "...",                  // NEW
      "handle": "...",              // NEW
      "id_type": "...",             // NEW
      "registry_id": "...",         // NEW
      "authoritative_registry_name": "...", // NEW
      "is_sponsor": "...",           // NEW
      "organization_number": "...",  // NEW
      "status": "...",               // NEW
      "normalized_name": "...",      // NEW
      "rdap_server": "...",          // NEW
      
  },

  "registrant_contact": {
      // older fields remain the same
      "id": "...",           // NEW
      "handle": "...",       // NEW
      "id_type": "..."       // NEW
  },

  "administrative_contact": {
      // older fields remain the same
      "id": "...",           // NEW
      "handle": "...",       // NEW
      "id_type": "..."       // NEW
  },

  "technical_contact": {
      // older fields remain the same
      "id": "...",           // NEW
      "handle": "...",       // NEW
      "id_type": "..."       // NEW
  },

  "billing_contact": {
      // older fields remain the same
      "id": "...",           // NEW
      "handle": "...",       // NEW
      "id_type": "..."       // NEW
  },

  "registry_data": {
      // older fields remain the same
      "secure_dns": "...",         // NEW (inside registry_data)
      "domain_handle": "...",      // NEW
      
      "domain_registrar": {
      // older fields remain the same
          "id": "...",                // NEW
          "handle": "...",            // NEW
          "id_type": "...",           // NEW
          "registry_id": "...",       // NEW
          "authoritative_registry_name": "...", // NEW
          "is_sponsor": "...",        // NEW
          "organization_number": "..." // NEW
      }
  }
}

This format shows exactly where v2 adds new fields while keeping every v1 field intact.


2. What Might Break When Upgrading

Only a few cases might require code changes:

i. Strict JSON parsing

If your parser doesn’t allow new fields, it may fail.
Fix: enable “ignore unknown fields” or update your model to include the new fields shown above.

ii. Logic that checks for missing objects

In v1, some objects were removed or set to null.
In v2, these objects exist and now contain more info.
Fix: check the specific fields you need instead of checking whether the whole object is null.

iii. Databases with fixed schemas

If you map every API field into columns, the new fields require additional schema changes.

iv. Logging

v2 includes more IDs and contact data. Avoid logging full WHOIS responses.


3. Summary

  • v2 = everything from v1 plus some new useful fields (shown above).
  • No old fields were removed or renamed.
  • Just update the URL and make sure your JSON parser accepts the new properties.
Author's Profile Picture
Usama Shabbir

Product Lead

A product lead with deep expertise in cybersecurity, adept at analyzing cyber threat data to enhance product resilience against emerging security threats.


Related Posts