Reference
Tool listing score fields, one by one
Design your listings table once and the monthly job writes itself. Here is each link-score column a directory can store, and the call that fills it.
SEO Tools AI research team ·
The columns, at a glance
| Column | Filled by | Credits | Refresh |
|---|---|---|---|
| dr | bulk_dr, up to 2,000 domains | 1 | Monthly |
| dr_checked_on | Your own job, the day you fetched | 0 | Every run |
| ref_domains | refdomains, sorted by your choice | 2 | Monthly, top listings only |
| top_anchors | anchors | 2 | Quarterly |
| top_pages | toppages | 2 | Quarterly |
| overview_blob | overview (free, no key) | 0 | On demand |
| rival_overlap | intersect, 2 to 10 domains | 2 | When you add a tool |
The columns that earn their space
Start with two. dr is the sort key, and dr_checked_on is the honesty column.
A score without a date looks like a fact, and a month later it is a rumour. The date stops that, and it also lets your job skip rows it refreshed an hour ago after a crash.
Treat everything else as optional. A comparison site that shows referring domains next to the rating gives readers a second number to cross-check, which is more useful than a prettier badge. Our backlink analysis tool page shows how that looks against other checkers.
Pair the columns with the glossary so readers see the same words you use in the back office, and with the sync recipe when you are ready to fill them.
The request parameters you will actually use
These are the parameters from the API, in the order a sync job needs them.
action what to do: domain, overview, bulk_dr, refdomains, anchors ...
q one domain, for single-domain actions
domains comma list, for bulk_dr (GET) or send it as a POST body
key your sk_ key, or use the Authorization: Bearer header
page which page of rows
per rows per page, 10 to 5000, up to 1,000 rows per billed call
sort column to sort by
order asc or descNaming and types that age well
Name columns after what they hold, not after a vendor. dr is fine for ours, but if you later add a second metric, dr_ours and da_moz will save you a migration.
Store the rating as an integer from 0 to 100, the date as an ISO string such as 2026-10-01, and counts as integers. A text column that holds 1.2k is a trap for the first person who sorts it.
Keep a source column too, with a short value like seotoolsai. It costs a few bytes and answers the question every future editor asks.
Every response carries ok. Authenticated ones also carry _credits, with the cost of that call and your remaining balance. Log both. Before you map any other field into a column, make one free domain call and read the JSON yourself.
Worked example: a hypothetical listing record
This is an invented example, not a real listing. Imagine a directory called ToolShelf with a listing for a fictional product, example-seo.test.
Its record holds dr 41, dr_checked_on 2026-10-01 and ref_domains 1,000. That fits the public formula, since log(1001) divided by log(20,000,000) times 100 rounds to 41.
A month later the job refetches and finds 1,800 referring domains, so the rating becomes 45. Only dr and the date change. The review text, the screenshots and the editor's notes stay exactly as written, because the score never touches them.
Field questions
Should I store the raw JSON for each listing?
Yes, once per refresh. Keep it in a single text or JSON column, then derive dr and the other display fields from it. When you change what you show, you can rebuild pages without calling the API again and paying twice.
What happens if a domain is not in the index?
Do not guess a score. Leave the dr cell empty and show no badge for that listing. Our index holds 181,132,097 domains, which is large but not the whole web, and a blank is more honest than a zero.
Do I need all of these fields on the public page?
No. Show the rating and its date, and perhaps referring domains for featured listings. Keep the rest in the back office for sorting, auditing and spotting listings whose numbers jump between months.