DEV Community: Mohammed Samaan

PDF to Markdown on Apify: pdf-text-extractor against pdf-to-markdown-ocr, with prices

Mohammed Samaan — Tue, 27 Oct 2026 18:58:46 +0000

Also published on Medium: https://medium.com/@samaanmohammed/pdf-to-markdown-on-apify-pdf-text-extractor-against-pdf-to-markdown-ocr-with-prices-e2c42339c0e1

We built one of the two tools compared here. Prices and user counts are from the public Apify pages on 27 October 2026.

If you feed PDFs to a retrieval pipeline or an LLM, you need clean Markdown, the page structure and a way to handle scanned pages. Two Apify actors do this. The one with more users is gochujang/pdf-text-extractor. The other is leadharbor/pdf-to-markdown-ocr, which is ours.

The leader

gochujang/pdf-text-extractor had 273 total users and 2,080 runs. Its listing says it extracts text, Markdown or RAG chunks, detects tables, and can optionally OCR scanned pages.

Its current price, in effect since 22 September 2026, is a start fee of $0.001, $0.02 per PDF and $0.001 per page. The pricing data has no separate OCR charge, so the listing does not tell you what an OCR page costs. Check the actor page before you run it on scans.

pdf-to-markdown-ocr

It returns one Markdown document per PDF and one entry per page. It also returns heading-based chunks with an approximate token count (characters divided by four) and a quality report for each file.

Pages with a text layer are read directly. Pages that are only pictures go through OCR. English and Arabic come built in. Any other OCR language is downloaded when a run needs it and is marked experimental. Arabic text comes back in reading order, first word first.

The quality report sets needsReview to true when an OCR page has a confidence under 70, when a page fails a text check, or when a page could not be read. A false value does not mean the file is correct.

Price

$0.004 per PDF converted and $0.007 per page read by OCR. Pages with a text layer add nothing per page. A file that fails, or a partial file, is not charged the PDF fee. Our README gives this example: a 20-page scan costs 20 x $0.007 + $0.004 = $0.144.

The same job at the published prices (our arithmetic, not measured runs):

Job	pdf-text-extractor	pdf-to-markdown-ocr
10-page text PDF	$0.031	$0.004
100-page text PDF	$0.121	$0.004
20-page scan, every page OCR	not stated in the listing	$0.144

The leader figures assume one PDF per run: $0.001 start, $0.02 for the PDF, and $0.001 for each page.

Quality

Our own benchmark uses 8 files, run locally with the same code as the Apify image. On an Arabic text PDF, word F1 was 0.987 raw and 1.000 with the page-marker lines removed. The scans are clean renders and the set is small, so this measures those files only. We have not run the leader on these files, so we make no quality claim against it.

Which one to pick

Text PDFs, many files, cost matters most: pdf-to-markdown-ocr is cheaper per file at these prices.
You want an actor with a longer public record: the leader has more users and more runs.
Scanned pages, and you want a confidence score for each page: pdf-to-markdown-ocr reports one. Check the leader's OCR behaviour and price before you pick it for scans.

Limits

Up to 100 links per run, 25 MB per file. The default is 100 pages per file, and the maximum is 500.
A conversion that makes no progress for 3 minutes, or runs past 30 minutes in total, returns the pages it finished, marked partial.
Skew up to 7 degrees is straightened. Stronger tilts, curved pages and mixed orientation on one page are not handled.
We have 2 users so far and no outside reviews. Test it on your own files first.

Try it: https://apify.com/leadharbor/pdf-to-markdown-ocr

PHP2Shell: a client-proof patch checklist for freelancers (CVE-2026-109618 / 109619)

Mohammed Samaan — Mon, 26 Oct 2026 08:48:45 +0000

Free checklist, written 26 Oct 2026. It is a technical checklist, not legal advice, not a security audit, and no guarantee that a server is safe.
For freelancers and small agencies who look after other people's PHP and WordPress servers.
Version 1.1 · written 26 Oct 2026 · facts are as reported by the sources listed at the end, each with a read date.

What this is: a checklist you can run on a server (a guess: about 30 minutes for a simple one) and the words to send your client afterwards. It is not legal advice, not a security audit, and not a guarantee that a server is safe. It does not replace updating PHP; updating is the only complete fix (Tenable, citing PHP).

Before you start: only work on servers you are contracted to manage, get the client's written go-ahead before you change settings, take a site offline or restore a backup, and keep a written record of every command you run and every change you make. The commands below only read client data, except the settings and updates in Steps 3 and 4. The file search in section 4 writes one results file into your own home folder; delete it when you are done.

1. What happened (as reported by the sources)

On 21 Oct 2026 the PHP project fixed two critical flaws, CVE-2026-109618 and CVE-2026-109619, together called "php2shell". Tenable, citing the PHP security team, gives both CVSS v4.0 9.2 (an earlier circulated score of 10.0 was wrong) and says an unauthenticated remote attacker can exploit them.
Amazon's honeypots recorded a first attempt on 17 Oct, four days before disclosure, and more on 21 Oct. Amazon says php2shell now sees broad exploitation attempts in the wild. CISA said it had not observed successful exploitation at publication; CISA revised its alert on 23 Oct, so that statement may be out of date. As of 23 Oct neither CVE was in CISA's KEV catalog (Tenable).
CISA says all PHP installations serving web requests are affected (Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed). CISA notes that PHP considers mod_php the highest risk.
Hostinger says the setting session.upload_progress.enabled = Off also protects against a further issue, CVE-2026-115560. We did not verify that CVE ourselves; check its status with your vendor.

2. Is this server affected?

PHP branch	Status (Tenable, read 26 Oct)
8.5.x before 8.5.12, 8.4.x before 8.4.27, 8.3.x before 8.3.36, 8.2.x before 8.2.35	Affected. Fixed in 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (CISA names the same four; php.net's release feed lists each as a security release dated 21 Oct 2026)
7.4 to 8.1	No official release; "minimal source backports from the PHP security team". Rely on your OS vendor's package and their advisory
5.4 to 7.3	End of life, no fix from the PHP project

Do not trust php -v alone. It reports the command-line binary, which can differ from the PHP that serves web requests (FPM, mod_php, LiteSpeed). Packaged and hosted builds can also be fixed without the version number changing (Hostinger says so for its managed hosting).

3. The triage, per server

Step 1: find every PHP on the box (CISA: inventory all installs including embedded ones, internet-facing first).

which -a php php-fpm php-cgi
php -v; php-fpm -v | head -1       # on Debian/Ubuntu the FPM binary is versioned, for example php-fpm8.3; the dpkg line below lists it
apachectl -M | grep -i php          # on RHEL-family use: httpd -M | grep -i php
ps -eo user,pid,ppid,etime,cmd --forest | grep -E 'php-fpm|php-cgi|lsphp|frankenphp|httpd|apache2' | grep -v grep | head -40
dpkg -l 'php*' | grep '^ii'         # Debian / Ubuntu: every installed PHP package
rpm -qa 'php*'                      # RHEL / Alma / Rocky / Remi: every installed PHP package

Errors here matter; do not hide them. A command that is missing on your system is itself information.

Step 2: is each installed package patched? Ask the package. Do this for every package from Step 1, not just one version.

# Debian / Ubuntu (needs network access)
apt changelog php8.3-fpm | grep -i -m3 109618      # change php8.3-fpm to each package you found
# RHEL / Alma / Rocky (package names vary, for example php-fpm or php83-php-fpm)
rpm -q --changelog php-fpm | grep -i -m3 109618
dnf updateinfo list --cve CVE-2026-109618          # if your dnf supports it

If the changelog names the CVE, the package contains a fix. A missing CVE line does not mean unpatched, and a CVE line does not mean the running process has it: the service must have been restarted after the update. If you cannot tell, check your OS vendor's security advisory before telling a client anything.
Managed hosts: Hostinger states that a PHP build date of 21 Oct 2026 or later means its fix is in. That rule is Hostinger's; other hosts have their own, so ask them (section 7).

Step 3: interim settings, only if you cannot update yet, and only with the client's consent. They reduce exposure; they do not make the server safe (Tenable).

For CVE-2026-109619: session.upload_progress.enabled = 0 in php.ini or the PHP-FPM pool config. Setting it with ini_set in code does not work (Hostinger). Side effect: applications that show upload progress bars may stop working.
For CVE-2026-109618: Tenable, quoting PHP, lists memory_limit=-1 set so applications cannot override it. Warning from us: an unlimited memory limit lets one runaway request exhaust the server's memory and take down every site on it. Use it only on a server you control, with consent, and prefer a container or cgroup memory cap alongside it (Tenable suggests one). On PHP 8.5 Tenable also lists fatal_error_backtraces=0.
Amazon also suggests blocking multipart file uploads for systems that cannot be patched quickly, after you assess the impact on the application (many sites need uploads).
Restart every PHP worker after any change (FPM, Apache, LiteSpeed).

Step 4: update. Move to a fixed release or your OS vendor's patched package, restart, then repeat Step 2.

Step 5: PHP 8.1 or older that cannot be updated. CISA's recommendation is to take such systems offline until they are patched or upgraded. Taking a client's site offline is the client's decision; give them the choice in writing. PHP 8.2 security support also ends on 31 Dec 2026 (Hostinger; php.net), so plan the move now.

4. Check for signs of compromise

The public sources give very little to search for. Here is all of it, and how to use it honestly.

Start your review from 17 Oct 2026, not from 21 Oct (Amazon).
Look for POST requests containing the string PHP_SESSION_UPLOAD_PROGRESS in form uploads (Amazon). Standard access logs do not record POST bodies, so this needs a WAF or ModSecurity audit log. If you have none, say so in your client report instead of claiming the server is clean.
Look for unexpected process execution and unexpected file changes on web servers (Amazon).

# GNU find (Debian / RHEL; not BusyBox, Alpine or macOS). Times follow the server's timezone.
# Files changed since 17 Oct 2026 with extensions attackers commonly use. Adjust the path. Read-only.
umask 077   # results file readable by you only
nice find /var/www -xdev -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.inc' -o -name '.htaccess' -o -name '.user.ini' \) \
  -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM  %u  %p\n' | sort > "$HOME/changed-since-17oct.txt"
wc -l "$HOME/changed-since-17oct.txt"        # then read the whole file; delete it when finished
# PHP processes' children (look for shells or unexpected binaries under php-fpm or apache)
ps -eo user,pid,ppid,etime,cmd --forest | head -80

Limits you must state to the client: file times can be forged and legitimate deploys also change files, and files with other extensions or in other paths are not covered. The web user is www-data on Debian, apache or nginx on RHEL, and a per-account user on cPanel.

Amazon's honeypot saw attempts from 103.216.220.92 (17 Oct) and 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188, 95.217.98.37 (21 Oct). These are shared anonymising infrastructure. Investigate hits from them; do not simply block them (Amazon).
A clean result from these checks means "we found nothing by these checks", not "we are safe".

5. If you find something

Tell the client immediately and let them decide. With their written go-ahead and after a fresh backup of the current state (keep it as evidence): take the site out of service, restore from a backup made before 17 Oct (note this can lose newer client data), update PHP, rotate every credential the site could read (database, API keys, admin and hosting passwords), and report what you found in writing. If the client is regulated they may have notification duties; that is for their lawyer, not this pack.

6. What to tell the client

Use the one-page report and the emails below. Rules: say what you checked, what you changed, what you could not check, and the date. Never write "secure" or "hack-proof".

7. Ask your host these four questions

Which PHP build is my account running, and does it include the fix for CVE-2026-109618 and CVE-2026-109619? How can I verify that myself?
When did you roll it out, and was every PHP version on my plan patched, including 8.1 and older?
Is session.upload_progress.enabled off at server level?
Do you keep WAF or audit logs I can search from 17 Oct onward? Reference point: Hostinger reports it completed its rollout on 22 Oct at 06:44 UTC. We did not verify any other host's status.

9. One-page client report (copy it)

Client: [name] · Site(s): [domains] · Server: [host / IP] · Checked by: [your name] · Date: [date] · Authorised by: [client name, date of written go-ahead]

Summary (one sentence)

[Pick one and delete the others]

Per the package changelog / host statement dated date, your server runs a PHP build that includes the fix, and the service was restarted on [date].
Your server was running a vulnerable PHP build. We updated it on [date], restarted the service and re-checked the package.
Your host has not confirmed a fix. With your consent we applied temporary settings and asked them to confirm. The risk remains until they do.
Your server runs PHP [version], which the PHP project no longer fixes. We recommend moving it by [date]; taking it offline until then is your decision.

What we checked

Check	Result	How
PHP builds present (CLI and web)	[list]	commands run, date
Fix present in the package	yes / no / could not verify	changelog or host statement, and restart date
Temporary settings applied (`session.upload_progress.enabled = 0`)	yes / no / not applied	file and restart date
Files changed since 17 Oct 2026	none found by this search (limits below) / [list]	file search of [paths and extensions]
Unexpected processes	none seen at the time / [list]	process list, time
Web firewall or audit log available for 17 Oct onward	yes / no

What we changed

[date, time, what, who]

What we could not check

[for example: no request-body logs, so we cannot rule out attempts; file times can be forged; the host did not answer question 3]

What this means

Finding nothing is not proof that nothing happened. The first attack attempts were reported on 17 Oct 2026. [one honest sentence about the residual risk]

Next steps

[action, cost] by [date]
[action, cost] by [date]

This is a technical check, not legal or insurance advice.

10. Emails (copy and edit)

A.Check completed (to your client)

Subject: Your website server: PHP security check completed

Hi [name],
On [date] we checked your server for the PHP vulnerability announced on 21 Oct 2026 (CVE-2026-109618 and CVE-2026-109619). [One sentence from the report summary.] The attached one-page report lists what we checked and changed.
One honest limit: [for example: we do not have request logs from before 21 Oct, so we cannot prove nothing was attempted]. We recommend [next step, with cost] by [date].
[your name]

B.Your host has not confirmed the fix (to your client)

Subject: Decision needed: your hosting provider has not confirmed the PHP fix

Hi [name],
A serious PHP vulnerability was announced on 21 Oct 2026, and Amazon reported exploitation attempts from 17 Oct. Your host has not yet confirmed that your plan is fixed. We asked them on [date] and have not had a clear answer.
What we have done meanwhile, with your earlier consent: [temporary settings]. These reduce the risk; they do not remove it.
Options: [wait until X / move to a host that confirms / update by Y]. Each has a cost: [cost]. Please reply with the option you choose and the cost you approve, in writing, and we will start only the work you name.
[your name]

C.To the host's support

Subject: Please confirm PHP2Shell fix for account [id]

Hello,
Please confirm for the account [id]: (1) which PHP build it runs and whether it includes the fix for CVE-2026-109618 and CVE-2026-109619, and how we can verify that ourselves; (2) the rollout date and whether all PHP versions on the plan, including 8.1 and older, are covered; (3) whether session.upload_progress.enabled is off at server level; (4) whether WAF or audit logs from 17 Oct onward are available to us.
Thank you,
[your name]

Sources (read 26 Oct 2026)

CISA alert, 21 Oct 2026 (revised 23 Oct): https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
Tenable FAQ: https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote
Amazon Threat Intelligence: https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
Hostinger: https://www.hostinger.com/blog/protecting-php2shell/
php.net release feed, read 26 Oct: https://www.php.net/releases/index.php?json&version=8.4 (8.4.27, 21 Oct 2026, tagged security; the same query with version=8.5, 8.3 and 8.2 returns 8.5.12, 8.3.36 and 8.2.35, all 21 Oct 2026) and https://www.php.net/supported-versions.php Not checked by us: your OS vendor's advisories, any host other than Hostinger, the KEV catalog after 23 Oct, and the commands on every distribution (they were reviewed, not run on a client server). Check those before you rely on this pack.

PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12: the version table for the 21 Oct 2026 security releases

Mohammed Samaan — Thu, 22 Oct 2026 14:50:35 +0000

On 21 October 2026 PHP published four releases tagged "security": 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two critical remote-code-execution flaws, CVE-2026-109618 and CVE-2026-109619 (the OSV database lists the same four versions as fixed). PHP 8.1 and older got no official fixed release.

Branch	Fixed in	Support ends (endoflife.date, read 22 Oct 2026)
8.5	8.5.12	2029-12-31
8.4	8.4.27	2028-12-31
8.3	8.3.36	2027-12-31
8.2	8.2.35	2026-12-31
8.1 and older	no official fix	8.1 ended 2025-12-31

What the sources say about exploitation: Rapid7 (21 October) says a viable exploit is expected to be made public soon, exploitation in the wild is expected, and it recommends updating on an emergency basis. Tenable reports that Amazon Threat Intelligence observed an exploitation attempt on 17 October and more on 21 October, and that Amazon says it is unclear whether those attempts would have succeeded against real systems. Reports differ between sources and change quickly, so check php.net and your host's notices for the current status.

Two practical points when you check your own servers:

Read the version from the PHP that serves the site. The command-line php -v can differ from PHP-FPM, and FPM must be restarted after an update.
Linux distribution packages can include a fix without changing the version number, so check your distribution's security notice before you decide a server is behind.

If it helps: I made a small free page where you type a version and it says whether it is at or above the fixed release and when its branch ends: https://samaanmohammed-art.github.io/php-patch-check/ . It only compares the number you type; it connects to nothing and does not scan or protect anything. For agencies with many sites I also made a $19 spreadsheet-and-email kit (disclosure: both are mine): https://samaanmohammed.gumroad.com/l/xvsyxe . Data as of 22 October 2026; no security or legal advice.

An SPF, DKIM and DMARC audit as one API call

Mohammed Samaan — Mon, 19 Oct 2026 14:49:19 +0000

Mail that lands in spam is often a DNS problem: a missing DMARC record, an SPF record that uses too many lookups, no DKIM key. Checking all of that by hand with dig gets old fast.

Here is the curl version, using the real gateway path:

curl --request GET \
  --url 'https://email-dns-health-spf-dkim-dmarc.p.rapidapi.com/v1/email-dns?domain=google.com' \
  --header 'x-rapidapi-host: email-dns-health-spf-dkim-dmarc.p.rapidapi.com' \
  --header 'x-rapidapi-key: YOUR_RAPIDAPI_KEY'

This endpoint does the lookups for a domain and returns MX, SPF, DMARC, DKIM, an overall grade and a list of issues ranked by severity. No mail is sent. Real capture for google.com:

{
  "domain": "google.com",
  "grade": "good",
  "mx": [
    {
      "host": "smtp.google.com",
      "priority": 10
    }
  ],
  "null_mx": false,
  "spf": {
    "present": true,
    "record": "v=spf1 include:_spf.google.com ~all",
    "multiple_records": false,
    "all": "softfail",
    "includes": [
      "_spf.google.com"
    ],
    "dns_lookups": 1
  },
  "dmarc": {
    "present": true,
    "record": "v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com",
    "policy": "reject",
    "subdomain_policy": null,
    "percent": 100,
    "aggregate_reports": [
      "mailto:mailauth-reports@google.com"
    ],
    "forensic_reports": [],
    "dkim_alignment": "r",
    "spf_alignment": "r"
  },
  "dkim": {
    "selectors_found": [],
    "checked": [
      "default",
      "google",
      "selector1",
      "selector2",
      "k1",
      "k2",
      "s1",
      "s2",
      "mail",
      "dkim",
      "mandrill",
      "smtp",
      "zoho",
      "mxvault"
    ]
  },
  "issues": [
    {
      "severity": "low",
      "message": "No DKIM key found on common selectors. This is not proof DKIM is missing: your provider may use a custom selector."
    }
  ],
  "meta": {
    "user": null
  }
}

(Trimmed: the mta_sts, tls_rpt and bimi fields are cut.)

The grade is good, fair or poor, and each entry in issues has a severity of high, medium, low or info. In the capture, SPF is present with a softfail all, DMARC has policy: reject, and the only issue is the low-severity DKIM note. The SPF object includes dns_lookups, which matters because SPF allows at most 10 lookups, and the code raises a high-severity issue when a record needs more. That check alone catches a classic silent failure. Run it before a campaign, or in a cron job across the domains you send from.

Limits worth knowing

DKIM is checked on a fixed list of common selectors only (see dkim.checked). As the issue message says, finding none is not proof DKIM is missing: google.com above shows selectors_found: [].
Everything comes from DNS, so it reports what is published, not whether your mail actually passes at a receiver.
If the DNS lookup itself fails you get a 502 ("DNS lookup failed. Try again later."); a missing or invalid domain is a 400.

Print the grade and any issues:

const res = await fetch(
  'https://email-dns-health-spf-dkim-dmarc.p.rapidapi.com/v1/email-dns?domain=google.com',
  {
    headers: {
      'x-rapidapi-host': 'email-dns-health-spf-dkim-dmarc.p.rapidapi.com',
      'x-rapidapi-key': process.env.RAPIDAPI_KEY,
    },
  }
);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const data = await res.json();
console.log(data.grade);
for (const i of data.issues) console.log(i.severity, i.message);

Listing and playground: https://rapidapi.com/samaanmohammed/api/email-dns-health-spf-dkim-dmarc

What an MX-only email check can and cannot tell you

Mohammed Samaan — Wed, 07 Oct 2026 10:45:13 +0000

Bad addresses at signup cost you bounces and sender reputation. Full mailbox verification services dial the recipient's mail server to ask whether the mailbox exists. This API does not, and that matters for how you use it. Here is what it returns and where it stops.

It sits next to two other APIs from the same account. The Disposable Email Checker is the list-only version (Stop Mailinator signups with one GET request), and Domain Trust Score judges the domain (Scoring an unknown domain 0 to 100). This one checks the address itself.

The shortest working call

curl --request GET \
  --url 'https://email-verifier38.p.rapidapi.com/v1/verify?email=test@gmail.com' \
  --header 'x-rapidapi-host: email-verifier38.p.rapidapi.com' \
  --header 'x-rapidapi-key: YOUR_RAPIDAPI_KEY'

JavaScript (Node 18+):

const email = 'test@gmail.com';const res = await fetch(
  'https://email-verifier38.p.rapidapi.com/v1/verify?email=' + encodeURIComponent(email),
  {
    headers: {
      'x-rapidapi-host': 'email-verifier38.p.rapidapi.com',
      'x-rapidapi-key': process.env.RAPIDAPI_KEY,
    },
  }
);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const data = await res.json();
const reject = ['invalid', 'disposable'].includes(data.status);
console.log(reject ? 'reject' : 'accept', data.score);

Python:

import os, requests

r = requests.get(
    "https://email-verifier38.p.rapidapi.com/v1/verify",
    params={"email": "test@gmail.com"},    headers={
        "x-rapidapi-host": "email-verifier38.p.rapidapi.com",
        "x-rapidapi-key": os.environ["RAPIDAPI_KEY"],
    },
    timeout=10,
)
r.raise_for_status()
d = r.json()
print("reject" if d["status"] in ("invalid", "disposable") else "accept", d["score"])

The response, field by field

Captured from the live API on 7 Oct 2026 (HTTP 200, 607 bytes):

{
  "email": "test@gmail.com",  "status": "unknown",
  "score": 72,
  "reason": "mx_only_no_smtp",
  "reason_detail": "Domain accepts mail. This API is MX-only — the mailbox itself was not dialed (SMTP port 25 is blocked on serverless platforms).",
  "method": "mx",
  "syntax_valid": true,
  "domain": "gmail.com",
  "mx_found": true,
  "mx_host": "gmail-smtp-in.l.google.com",
  "is_disposable": false,
  "is_role": false,
  "is_free_provider": true,
  "has_tag": false,
  "base_email": "test@gmail.com",  "typo_suggestion": null,
  "domain_has_spf": true,
  "domain_has_dmarc": true,
  "checked_at": "2026-10-07T10:00:52.056Z",
  "duration_ms": 9,
  "meta": { "user": "..." }
}

status is one of valid, invalid, disposable, risky or unknown. score runs from 0 to 100.
reason and reason_detail explain the verdict. Here the domain accepts mail but the mailbox was not contacted, so the answer is unknown, not valid.
syntax_valid, domain, mx_found and mx_host are the syntax and DNS checks.
is_disposable, is_role (such as info@) and is_free_provider are separate booleans. has_tag and base_email handle plus-addressing.
typo_suggestion offers a correction for misspelled domains, or null.
domain_has_spf and domain_has_dmarc describe the domain's DNS, not the mailbox.
duration_ms is the server-side time (9 ms here, from the response itself). The playground round trip was about 1.5 s.
meta.user holds the caller's account name, shown as "...".

Two more captures from the same day, with the same 21 keys. someone@mailinator.com returned status: "disposable", score: 5, reason: "disposable_domain", mx_found: false. not-an-email returned status: "invalid", score: 0, reason: "bad_syntax", syntax_valid: false and domain: null. Both were HTTP 200, so a bad address is a result and not an error status.

Using it at signup

Reject invalid and disposable, accept the rest, and confirm with a real confirmation email later. Do not reject unknown, because it is the normal answer for a good Gmail address.

What it does not do

It never contacts the mailbox. SMTP port 25 is blocked on serverless platforms, so this API cannot tell you a specific mailbox exists.
It does not detect catch-all domains.
It cannot promise an address will receive mail or will not bounce. valid means the checks it runs passed, nothing more.
A single GET checks one address. A POST to /v1/verify with an emails array checks a small batch, with a maximum of 10 per request.

Errors

A malformed address is a normal 200 with status: "invalid", as shown above. Gateway failures such as a missing or wrong key, or a used-up quota, return RapidAPI's own error before the request reaches the API. I did not re-run other error cases for this post, so check the listing's endpoint documentation for the current ones.

Status	Meaning
200	The address was checked, whatever the verdict
Non-2xx	Gateway or API failure. Throw, log, and let the user continue rather than blocking signup

Plan

The free Basic plan on the listing currently shows 300 requests per month. Pro is $19 per month for 3,000.

Listing and playground: https://rapidapi.com/samaanmohammed/api/email-verifier38

Scoring an unknown domain 0 to 100 from public signals, with every penalty documented

Mohammed Samaan — Wed, 07 Oct 2026 10:13:03 +0000

A lead or signup arrives from a domain you have never seen. Is it a throwaway, a week-old registration, or a company with a valid certificate and a DMARC policy? Checking that by hand means five lookups. This API runs them in one call and returns a score plus the reasons.

If you only need the disposable-domain part, the Disposable Email Checker from the same account does just that: Stop Mailinator signups with one GET request. This one adds domain age, SSL and email DNS on top.

The shortest working call

curl --request GET \
  --url 'https://domain-trust-score.p.rapidapi.com/checkTrust?domain=stripe.com' \
  --header 'x-rapidapi-host: domain-trust-score.p.rapidapi.com' \
  --header 'x-rapidapi-key: YOUR_RAPIDAPI_KEY'

JavaScript (Node 18+):

const res = await fetch(
  'https://domain-trust-score.p.rapidapi.com/checkTrust?domain=stripe.com',
  {
    headers: {
      'x-rapidapi-host': 'domain-trust-score.p.rapidapi.com',
      'x-rapidapi-key': process.env.RAPIDAPI_KEY,
    },
  }
);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const data = await res.json();
console.log(data.trustScore, data.riskLevel, data.flags);

Python:

import os, requests

r = requests.get(
    "https://domain-trust-score.p.rapidapi.com/checkTrust",
    params={"domain": "stripe.com"},
    headers={
        "x-rapidapi-host": "domain-trust-score.p.rapidapi.com",
        "x-rapidapi-key": os.environ["RAPIDAPI_KEY"],
    },
    timeout=20,
)
r.raise_for_status()
d = r.json()
print(d["trustScore"], d["riskLevel"], d["flags"])

The call does DNS, registry and TLS lookups, so expect a second or two. The captures below took 2.1 s and 0.9 s. Set a timeout.

The response, field by field

Captured from the live API on 7 Oct 2026 (HTTP 200, 795 bytes):

{
  "domain": "stripe.com",
  "trustScore": 100,
  "riskLevel": "low",
  "flags": [],
  "disposable": false,
  "disposableMatchedDomain": null,
  "freeProvider": false,
  "registeredDomain": "stripe.com",
  "domainAgeDays": 11348,
  "registeredAt": "1995-09-12T04:00:00.000Z",
  "registrar": "SafeNames Ltd.",
  "domainAgeStatus": "ok",
  "domainAgeNote": null,
  "ssl": {
    "https": true,
    "valid": true,
    "error": null,
    "issuer": "DigiCert, Inc.",
    "validTo": "2026-12-10T23:59:59.000Z",
    "daysRemaining": 64
  },
  "email": {
    "hasMx": true,
    "mxHosts": [
      "aspmx.l.google.com",
      "alt1.aspmx.l.google.com",
      "alt2.aspmx.l.google.com",
      "aspmx2.googlemail.com",
      "aspmx3.googlemail.com"
    ],
    "spf": true,
    "dmarc": true,
    "dmarcPolicy": "reject",
    "dkimSelectorsFound": ["google", "mandrill", "s1", "s2"],
    "dkimWildcardDns": false
  },
  "listsUpdatedAt": "2026-10-05T10:09:51.295Z",
  "meta": { "user": "..." }
}

trustScore starts at 100 and loses a fixed penalty per flag, never going below 0. riskLevel is low at 75 or more, medium from 45 to 74, high below 45.
flags is the part to read. It lists why the score is what it is. For stripe.com it is empty.
disposable, disposableMatchedDomain, freeProvider come from public disposable-domain lists.
domainAgeDays, registeredAt, registrar come from the public registry (RDAP). domainAgeStatus says ok or why no age is available.
ssl is a TLS check on port 443 of the domain you sent, including days until expiry.
email is DNS only: MX hosts, SPF, DMARC policy and which of 16 common DKIM selectors exist.
meta.user holds the caller's account name, shown as "...".

A bad one, mailinator.com (also 7 Oct 2026, 734 bytes), comes back with trustScore: 30, riskLevel: "high" and flags: ["disposable_domain"]. That is 100 minus the 70-point disposable penalty. The other fields (age 8,497 days, valid SSL, SPF and DMARC present) show the score does not mean the domain is new or broken. It means it is a throwaway mail provider.

The penalties

Flag	Points
`disposable_domain`, `domain_does_not_exist`	70
`domain_does_not_resolve`	40
`domain_under_30_days_old`	30
`ssl_invalid`	25
`domain_under_90_days_old`, `no_https`	15
`no_mx_records`	10
`no_spf`, `no_dmarc`	8
`domain_under_1_year_old`, `ssl_expires_within_14_days`	5
`dmarc_policy_none`	3
`no_dkim_on_common_selectors`	2

free_email_provider and domain_age_unavailable appear as context and cost nothing. If you disagree with these weights, ignore trustScore and apply your own rules to flags, ssl, email and domainAgeDays.

What it does not do

The score is a heuristic from public signals. It is not a guarantee of safety, a certification or a fraud verdict.
Domain age needs a public RDAP service. In the project's tests of 150 business domains, .ae, .io, .co, .me, .ru and .pk had none, and .au returned no date or was rate-limited. domainAgeStatus explains this and no penalty applies.
DKIM cannot be listed from DNS, so 16 common selectors are probed. Finding none does not prove DKIM is absent, which is why the penalty is only 2.
SSL is checked on the domain you send. A mail-only domain with no website gets no_https.
It does not look at page content, reputation feeds or blocklists.

Errors

Status	When	Body
200	Domain read and checked (a domain that does not exist is still 200, with a low score)	The result above
400	`domain` missing	`{"error":"Pass ?domain=<domain>, for example example.com.","code":400}`
400	`domain` not readable	`{"error":"Could not read a valid domain from this input.","code":400}`
405	Any method other than GET	`{"error":"Use GET /checkTrust?domain=<domain>.","code":405}`
502	Unexpected failure inside the API	`{"error":"Check failed: ...","code":502}`

The error bodies are from the API's own documentation and were not re-run on 7 Oct. Gateway failures (bad key, quota used up) return RapidAPI's own error.

Plan

The free Basic plan on the listing currently shows 300 requests per month. Pro is $29 per month for 10,000.

Listing and playground: https://rapidapi.com/samaanmohammed/api/domain-trust-score

Stop Mailinator signups with one GET request

Mohammed Samaan — Wed, 07 Oct 2026 10:08:56 +0000

If your free trial lets anyone in with an email address, someone will sign up as x@mailinator.com forty times. A list lookup at signup is the cheapest first filter. This API does that lookup without you maintaining the lists.

The shortest working call

Subscribe to the free plan on the listing (link at the bottom), copy your key, and run:

curl --request GET \
  --url 'https://disposable-email-checker16.p.rapidapi.com/checkDisposable?email=throwaway@mailinator.com' \
  --header 'x-rapidapi-host: disposable-email-checker16.p.rapidapi.com' \
  --header 'x-rapidapi-key: YOUR_RAPIDAPI_KEY'

JavaScript (Node 18+):

const res = await fetch(
  'https://disposable-email-checker16.p.rapidapi.com/checkDisposable?email=' +
    encodeURIComponent('throwaway@mailinator.com'),  {
    headers: {
      'x-rapidapi-host': 'disposable-email-checker16.p.rapidapi.com',
      'x-rapidapi-key': process.env.RAPIDAPI_KEY,
    },
  }
);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const data = await res.json();
if (data.disposable) console.log('blocked:', data.matchedDomain);

Python:

import os, requests

r = requests.get(
    "https://disposable-email-checker16.p.rapidapi.com/checkDisposable",
    params={"email": "throwaway@mailinator.com"},    headers={
        "x-rapidapi-host": "disposable-email-checker16.p.rapidapi.com",
        "x-rapidapi-key": os.environ["RAPIDAPI_KEY"],
    },
    timeout=10,
)
r.raise_for_status()
data = r.json()
print(data["disposable"], data["matchedDomain"])

The response, field by field

Captured from the live API on 7 Oct 2026 (HTTP 200, 322 bytes):

{
  "input": "throwaway@mailinator.com",  "type": "email",
  "domain": "mailinator.com",
  "disposable": true,
  "freeProvider": false,
  "matchedLists": [
    "disposable-email-domains",
    "disposable",
    "mailchecker",
    "burner-email-providers"
  ],
  "matchedDomain": "mailinator.com",
  "listsUpdatedAt": "2026-10-05T10:09:51.295Z",
  "meta": {
    "user": "..."
  }
}

(meta.user holds the account name of the caller, shown as "..." here.)

input and type: what you sent, and whether it was read as an email or a bare domain. A URL also works; only the domain is used.
domain: the domain that was extracted and checked.
disposable: true if the domain is on at least one list. Subdomains are matched against their parent domain, so you do not need to strip them first.
freeProvider: true for providers such as Gmail. It is always false when disposable is true.
matchedLists: which of the five merged public lists flagged the domain. Four of five agree here. A domain flagged by one list is a weaker signal than one flagged by all.
matchedDomain: the entry that matched, or null.
listsUpdatedAt: when the lists were last refreshed. They refresh when older than 7 days.

A free provider looks like this (gmail.com, also captured 7 Oct 2026, 213 bytes): type is domain, disposable is false, freeProvider is true, matchedLists is [] and matchedDomain is null. That split lets you reject throwaway domains outright while only flagging free providers on a B2B form.

What it does not do

A domain missing from the lists is not proof the address is real or safe. New throwaway domains appear daily.
The lists are community-maintained, so false positives happen. Use matchedLists to see how many agree.
It never contacts the mailbox. It does not check that the address exists, that the domain has mail servers, or that the user can receive mail. For that you need a confirmation email.
It is a list lookup. It does not score a domain on age or reputation.

Errors

Status	When	Body
200	Input read and checked	The result above
400	`email` missing	`{"error":"Pass ?email=<email address or domain>.","code":400}`
400	`email` not readable	`{"error":"Not a valid email address.","code":400}`
405	Any method other than GET	`{"error":"Use GET /checkDisposable?email=<address or domain>.","code":405}`
502	Unexpected failure inside the API	`{"error":"Check failed: ...","code":502}`

The 400, 405 and 502 bodies are from the API's own documentation and were not re-run on 7 Oct. Requests that fail at the RapidAPI gateway (a missing or wrong key, or a quota that is used up) return RapidAPI's own error, not this shape.

Plan

The free Basic plan on the listing currently shows 1,000 requests per month. Paid plans start at $29 per month.

Listing and playground: https://rapidapi.com/samaanmohammed/api/disposable-email-checker16