Implementation references
AiVikings.ai exposes availability checks for up to 200 candidates per REST request, while registration requests operate on one domain at a time. Build the run log around each paid result rather than treating the whole portfolio as an atomic purchase.
Use the operation reference, live pricing guide and portfolio example to implement and test the read path. The example is read-only and its fixture mode is not a registrar sandbox.
When you register hundreds of domains through an API, something will eventually stop halfway: a timeout, a rate limit, a crashed script or a laptop that went to sleep. What saves you is a run log: a small file that records what you asked for, what you were told, and what the account says. With it, you can resume safely and never guess what was bought.
The post on what to do after a timeout covers one request. This post is about a thousand of them.
The delivery driver’s sheet
A delivery driver carries a sheet with every parcel on it. Each line has a tick for delivered, a note for not home, and a time. If the van breaks down at lunch, someone else can take the sheet and finish the round. Nobody delivers a parcel twice, and nobody wonders what happened to the third one.
A bulk registration needs the same sheet. Without it, a stopped run becomes a mystery, and a mystery with a payment attached is the worst kind.
Before the run
Four things should be true before you send the first registration:
- Availability is checked. See how to check 500 domain names in batches. Treat errors as unknown, and not as unavailable.
- Prices are quoted. A name can be available and still priced as a premium. The post on availability, quotes and registration explains why these are separate facts.
- Contacts are ready. Prepare reusable contacts first, as described in how to prepare reusable contacts.
- The budget is set. Decide the total you are willing to spend, and have the balance in place.
The run log
Use a plain file: a spreadsheet, a CSV or a database table. One row per name. These are the columns I would use:
| Column | What it holds |
|---|---|
| run_id | A name for this run, so you can tell runs apart |
| domain | The exact name |
| quoted_price | The price you were quoted, with currency and time |
| requested_at | When you sent the registration request |
| outcome | registered, failed or unknown |
| receipt | The order or reference the API returned, if any |
| checked_at | When you last confirmed the state against the account |
| note | Anything you want to remember |
Here is a hypothetical example of a few rows:
run_id,domain,quoted_price,requested_at,outcome,receipt,checked_at,note
2026-10-run-1,alpha-example.com,12.00 USD,2026-10-26T09:00:01Z,registered,ord-1001,2026-10-26T09:05:00Z,
2026-10-run-1,beta-example.com,12.00 USD,2026-10-26T09:00:02Z,unknown,,,timeout
2026-10-run-1,gamma-example.com,12.00 USD,,,,,not sent yetWrite the row before you send the request, and update it after. A row that says “sent, no answer” is far more useful than a row that is missing.
The resume rule
When you restart a stopped run, do this for every row, in this order:
- Outcome is registered? Skip it.
- Outcome is failed? Look at why. Retry only if the reason is one you can fix.
- Outcome is unknown, or the request was sent without an answer? Do not send the request again. First, look at the account: is the domain there? If it is, record it as registered with the receipt. If it is not, and enough time has passed, only then retry.
- Not sent? Send it, and log it.
The rule that matters is the third one. A retry of a paid request that already succeeded is how people end up with an extra bill, or an error that says the domain is already registered. Check the account, and not your memory.
Pace and limits
Do not send a thousand requests at the same moment. Work in small batches, keep a steady pace, and respect the limits in the documentation. If you hit a limit, slow down and let the log tell you where you were.
A spend ceiling
Put a ceiling in the script: a total amount at which the run stops by itself. Keep a running total in the log. If the run would pass the ceiling, it stops and tells you. A runaway script with a payment method attached is not a hobby.
When you are done
Compare the log with the account. Count the registered names in both. They should match. If they do not, find the difference before you do anything else, and write down what it was.
Then add the new names to your inventory with their cost and renewal date. The guide to domain portfolio management shows how, and the post on keeping the purchase decision with the holding covers the record. If you want to know what the checks should look like underneath, the post on why a zone file is not an availability check is a good companion, and the page for domain investors has the rest.
Questions people ask
What should a bulk registration log contain? The name, the quote, when you sent the request, the outcome, the receipt and when you last checked the account.
What do I do when a request times out? Do not retry at once. Check the account for the domain first.
How do I avoid duplicates? Write the row before you send, and check the account before any retry.
How many domains should I send at once? Work in small batches that stay within the limits in the documentation.
Sources
- AiVikings.ai documentation
If your log has a column I have missed, tell me in the chat on the website.
/Thomas
When this is not the right fit
Use a dashboard when a one-off manual task is simpler. Programmatic domain operations still require an authorized account, current facts and an owner for exceptions.