How to use Rules to fetch domain Whois Data, parse the data and save it to fields? For a domain management website I would like to import all Whois data to entity fields. 
A domain is an (ECK) entity, with the fields corresponding with the Whois data. 

There are public Whois api's available, such as http://bulkwhoisapi.com/ but I'm not sure which one would best serve the import method I want to use.

How can this be accomplished?

Note: My preference is to use Rules and not create a custom module.
When you want to use Rules, you still need to have a connection between Rules and the API. The Rules module by default cannot make API requests (though some contrib module might provide it).

As an alternative I'd like to present to you, the Feeds module.


  Import or aggregate data as nodes, users, taxonomy terms or simple
  database records.
  
  
  One-off imports and periodic aggregation of content
  Import or aggregate RSS/Atom feeds
  Import or aggregate CSV files
  Import or aggregate OPML files
  PubSubHubbub support
  Create nodes, users, taxonomy terms or simple database records from import
  Extensible to import any other kind of content
  Granular mapping of input elements to Drupal content elements
  Exportable configurations
  Batched import for large files
  


This module is designed to perform (periodic) requests to external API's and store the data locally. Plus there are a lot of video tutorials out there to help you with this.

The downside is that feeds by default cannot save to an ECK entity (it can save into a node). The Feeds ECK Processor is currently under review and not yet ready for production. The Feeds Entity Processor might work (suggested on the Feeds ECK Processor application page), but this is unconfirmed. Or you can use Feed Rules to obtain the data with Feeds and then send it to Rules where you can attach it to your entity.

So far this seems possible. The only problem is that feeds does not accept input parameters, so you'd have to create a new feeds importer for every domain...

It is probably not the answer you were hoping for, but perhaps someone else knows how to resolve this last missing piece.