DEV Community: locaihost data

How the top 1,000 websites handle email security in 2026: DMARC, SPF, BIMI and who hosts their email

locaihost data — Sat, 10 Oct 2026 14:47:39 +0000

Anyone can put any domain in the From line of an email. Three DNS records decide whether the receiving server believes it. SPF lists the servers allowed to send for a domain. DMARC tells receivers what to do when a message fails those checks: nothing (p=none), send it to spam (p=quarantine) or refuse it (p=reject). BIMI then lets a domain that enforces DMARC show its logo in the inbox.

Since February 2024, Google and Yahoo have required DMARC from anyone sending them bulk mail, so most large senders have published something. We wanted to know what they published. On 10 October 2026 we looked up the email DNS of the 1,000 most popular websites on the Tranco list (list 8PX5V) and recorded their policies and their mail hosts.

Five findings:

85% publish DMARC, but only 69% enforce it. 84.5% of the 1,000 domains have a DMARC record. 69.4% set it to quarantine or reject for all mail, and 47.4% reject outright. The other 13.6% publish p=none, which only monitors.
Rank matters a little. 62% of the top 100 reject spoofed mail, against 46% of domains ranked 101–1,000.
SPF is almost universal and usually strict. 89.6% publish SPF. Of those, 53.8% end it with -all (hard fail) and 40.4% with ~all (soft fail).
BIMI has taken off; MTA-STS hasn't. 21.3% publish a BIMI record, against only 4.5% for MTA-STS, which forces encrypted delivery.
Google hosts more of this mail than anyone. Of the 875 domains that accept mail, 37.3% use Google Workspace and 17.4% Microsoft 365. Proofpoint filters 9.0% before the mail reaches the mailbox.

DMARC and SPF by rank

Measure	Top 100	101–1,000	All
DMARC record	87.0%	84.2%	84.5%
DMARC enforced	76.0%	68.7%	69.4%
DMARC `p=reject`	62.0%	45.8%	47.4%
SPF record	93.0%	89.2%	89.6%
BIMI record	27.0%	20.7%	21.3%
MTA-STS policy	11.0%	3.8%	4.5%

"Enforced" means quarantine or reject, applied to 100% of mail. Rank is the position among the 1,000 domains we kept, in Tranco order.

Across all 1,000 domains, the DMARC policy split was 474 at reject, 235 at quarantine and 136 at none. 155 had no record. Few hedged: only 15 of the 845 records (1.8%) applied their policy to less than 100% of mail. 24 (2.8%) rejected spoofs of the main domain but used a weaker policy for its subdomains.

A p=none record is usually a first step. A domain watches the reports, finds its legitimate senders, then tightens the policy. Most of the 136 p=none domains are doing that: 85% of them ask for aggregate reports. Some very large names are still there, though, including samsung.com and yandex.ru, and Microsoft's consumer mail domains outlook.com, live.com and msn.com. For consumer mailbox domains, p=none is often deliberate. Mailing lists and forwarding break authentication, and a strict policy would bounce real mail. A company domain doesn't have that excuse.

The SPF split matters less than it looks. Under DMARC, a receiver judges a message by the DMARC result, so -all versus ~all mostly matters to receivers that don't check DMARC. 37 domains (4.1% of those with SPF) have no all of their own and hand over to another record with redirect=, and 15 use the neutral ?all. None of the 1,000 used +all, which would let any server send as the domain.

Who hosts the mail

Of the 1,000 domains, 875 have an MX record, so they accept mail. The rest are mostly link shorteners, download hosts and developer infrastructure.

Mailbox host	Domains	Share
Google Workspace	326	37.3%
Microsoft 365	152	17.4%
Own mail servers	147	16.8%
Unrecognised MX host	105	12.0%
Gateway, mailbox hidden	81	9.3%
Amazon WorkMail / SES	13	1.5%
Tencent Exmail	8	0.9%
Alibaba Mail, Yandex 360	6 each	0.7% each
Zoho Mail	5	0.6%
Other named providers (12)	26	3.0%

Base: the 875 domains that accept mail. "Own mail servers" means MX hosts under the domain's own name. Google's and Microsoft's own domains count under their own services.

The rows that are not Google or Microsoft deserve a closer look. "Own mail servers" means the MX host is under the domain's own name, as with apple.com and paypal.com. Most of the "unrecognised" group is the same thing one step removed. imdb.com receives mail on amazon.com servers, webex.com on cisco.com servers and vk.com on mail.ru servers. Together, the two groups make up 28.8% of the domains that accept mail.

In front of the mailbox, 124 domains (14.2% of those accepting mail) use a security gateway that filters inbound mail first:

Inbound gateway	Domains	Share of the 875
Proofpoint	79	9.0%
Mimecast	24	2.7%
Cisco Secure Email	11	1.3%
Five others	10	1.1%
None detected	751	85.8%

The five others: Broadcom and Trend Micro (3 each), Barracuda (2), Sophos and Hornetsecurity (1 each).

Behind those gateways, SPF identifies the mailbox in 43 of the 124 cases: 24 use Microsoft 365 and 19 Google Workspace. The rest list only the gateway or their own servers in SPF, so the mailbox host stays hidden.

Who enforces DMARC

Enforcement differs by mail host. Domains on Google Workspace enforce DMARC more often than those on Microsoft 365. Domains behind a gateway enforce it most often. This is a correlation, not a cause: buying Proofpoint and setting p=reject both point to a company with a dedicated email-security team.

Mail host	Domains	DMARC enforced
Gateway, mailbox hidden	81	86.4%
Google Workspace	326	82.2%
Microsoft 365	152	72.4%
Unrecognised MX host	105	67.6%
Own mail servers	147	66.7%
No MX (accepts no mail)	125	37.6%

The last row is the weakest point. A domain that never sends mail can still be forged, and attackers like such domains because nobody watches them. The standard lock-down is two records: v=spf1 -all (no server may send) and DMARC p=reject. Only 31 of the 125 non-mail domains (24.8%) have both. 76 (60.8%) have either no DMARC record or p=none.

By top-level domain, .com led: 75.0% of its 596 domains enforce DMARC and 51.0% reject. Country-code domains followed at 63.5% (159 domains), then government, education and international bodies at 60.0% (35), and .org and .net at 57.0% (128).

Who reads the reports

DMARC lets a domain ask receivers for daily aggregate reports (the rua tag). 91.5% of DMARC records ask for them. 63.6% send them to an outside service, usually a vendor that turns the XML into dashboards. Counting each domain once per vendor:

Report receiver	Domains
Valimail (`vali.email`)	74
Proofpoint	71
dmarcian	55
Agari (Fortra)	29
Mimecast DMARC Analyzer	28
Cloudflare	26
Red Sift OnDMARC	22
Postmark	22

13 domains send their reports to dhs.gov, the collection point used by US federal civilian agencies. 11 of them are agencies such as nasa.gov and whitehouse.gov, and the other two are the companies Box and Dynatrace. Another 22 report to google.com, all of them Google properties such as youtube.com and android.com.

DNS and CDN

The same lookups show who runs the infrastructure. AWS Route 53 answers DNS for 24.6% of the 1,000 domains. Cloudflare answers for 16.3%, and 15.7% run their own name servers. Akamai answers for 9.4% and NS1 for 4.4%. 31.2% publish a CAA record that limits which certificate authorities may issue for them. Of the 902 domains with a homepage, Cloudflare serves 25.7%, Akamai and Amazon CloudFront 14.1% each, and Fastly 9.0%. We detected no CDN for the other 33.8%.

Methodology and caveats

Domains. Tranco list 8PX5V, generated 9 October 2026 from 30 days (10 September to 9 October) of Chrome UX Report, Farsight, Majestic, Cloudflare Radar and Cisco Umbrella data, as registrable domains. We removed 73 infrastructure host names listed by hand (CDN, API and telemetry domains such as gstatic.com and akamaiedge.net). We then dropped any domain that neither served a homepage nor had an MX record: 197 more, mostly CDN and device-telemetry hosts. A homepage behind a bot wall (HTTP 401, 403 or 429) counts as served. The first 1,000 remaining domains, down to Tranco rank 1,272, are the sample. The script lists every exclusion.
Snapshot. All lookups ran on 10 October 2026, 14:03–14:40 UTC, from Apify's cloud. DNS records change, so this is one day's picture.
What "detected" means. A record counts if it exists in public DNS and parses: SPF is a v=spf1 TXT record at the domain, DMARC a v=DMARC1 record at _dmarc, BIMI a v=BIMI1 record at default._bimi, MTA-STS a v=STSv1 record at _mta-sts. We didn't check BIMI logos or certificates, and we didn't fetch MTA-STS policy files. Mail hosts and gateways are matched from MX host names, and from SPF includes when a gateway hides the mailbox. A host we have no rule for is reported as unrecognised, not guessed. Domains with a null MX (RFC 7505) count as having no MX.
Cross-check. About an hour after the run, we re-resolved MX, SPF, DMARC and BIMI for all 1,298 domains through public resolvers. The results disagreed on 7 MX answers (all of them null MX, which the two tools count differently), 2 SPF records, 2 DMARC policies and no BIMI records. One domain, indeed.com, answered our cloud resolver with 0.0.0.0 and no MX. It was therefore dropped from the sample, though it does accept mail.
Reproducible. Four Node.js scripts fetch the list, run the lookups, compute every figure (results.json) and run the cross-check. We use only company domains, and we collect no personal data. Report addresses are reduced to the receiving domain.

Source: Tranco list 8PX5V (tranco-list.eu); DNS, HTTP and TLS lookups by locaihost data, 10 October 2026.

The data came from our Domain Intel Actor on Apify, which returns these fields (email host, gateway, SPF, DMARC, BIMI, MTA-STS, DNS, CDN, TLS) for any list of domains. To check your own suppliers, customers or portfolio the same way, it costs $3 per 1,000 domains.

Who actually sponsors H-1B workers in 2026, and what they offer to pay

locaihost data — Sat, 10 Oct 2026 13:56:26 +0000

Every H-1B petition starts with a Labor Condition Application (LCA) filed with the US Department of Labor. On it, the employer gives the job title, the worksite and the wage it will pay. The Labor Department publishes these forms every quarter. We combined all of them from 1 October 2023 to 30 June 2026 (fiscal year 2024 to the third quarter of FY2026), along with the PERM green-card filings for the same period. That comes to 1.57 million LCA cases and 374,000 PERM cases from 153,000 employers.

Five findings stand out:

The largest filers are cutting back, and most of the cut comes from outsourcing firms. Comparing like with like (October to June of each year), certified LCAs fell 8.1% in FY2026. Twenty large IT-services firms filed 31.9% fewer and account for a third of the drop, though they filed only 8.7% of FY2025's applications.
Most sponsors file one application a year. Of the 63,545 employers with a certified LCA in FY2025, 51.6% had exactly one.
Who you work for affects the wage more than the visa does. The median offered wage for software-engineer titles was $203,350 at Meta and $112,986 at Tata Consultancy Services.
Green-card sponsorship varies widely. Intel had 32 PERM certifications for every 100 LCAs. Infosys had fewer than one.
Denials are rare: 0.68%. That figure says very little, and the reason is explained below.

Who files the most

In FY2025, the last complete year, the Labor Department certified 541,597 LCAs, 8.2% more than the 500,329 in FY2024. Of these, 529,432 were for H-1B. The rest were for the country-specific versions: 8,858 E-3 (Australia), 1,940 H-1B1 (Chile) and 1,367 H-1B1 (Singapore).

The table ranks employers as they appear on the forms. These are legal entities, not corporate groups, so Amazon's four main filing entities are counted separately. Combined, the four filed 22,914 in FY2025.

#	Employer (legal entity)	FY2024	FY2025	Oct–Jun FY25	Oct–Jun FY26	Change	Median offered wage, FY2025
1	Amazon.com Services	14,584	15,493	12,630	13,922	+10.2%	$154,600
2	Cognizant Technology Solutions US	11,226	11,090	8,600	5,774	−32.9%	$109,782
3	Ernst & Young U.S.	9,828	9,601	8,161	5,168	−36.7%	$143,517
4	Microsoft	9,491	9,215	7,417	5,159	−30.4%	$170,766
5	Google	8,815	8,800	7,861	7,423	−5.6%	$184,000
6	Tata Consultancy Services	9,611	7,796	6,491	2,880	−55.6%	$85,634
7	Meta Platforms	5,911	6,627	5,717	5,278	−7.7%	$203,350
8	Apple	3,460	6,283	4,822	4,870	+1.0%	$175,800
9	Infosys	5,896	5,757	3,876	4,568	+17.9%	$92,581
10	Deloitte Consulting	2,693	4,255	3,215	2,622	−18.4%	$138,423

Certified LCAs by decision date. "Oct–Jun" compares the same nine months of each fiscal year, because the FY2026 data ends on 30 June 2026.

Like-for-like, total certified LCAs fell from 436,875 to 401,397. Most of the drop came early in the year. Compared with a year before, the October–December 2025 quarter was down 22.2%, January–March was down 7.7% and April–June was down 2.3%. A presidential proclamation of 19 September 2025 added a $100,000 payment to certain new H-1B petitions just before that first quarter. (A federal court vacated the guidance implementing that payment on 8 June 2026, and the litigation is ongoing.) The data shows when filings fell but not why, and an LCA is filed before the petition, so these figures can't separate the petitions the payment applied to from those it didn't.

Change wasn't spread evenly. Of the 68 employers with at least 500 certified LCAs in October–June FY2025, 44 filed fewer in the same months of FY2026. The largest falls were IBM (−63.8%), Tata Consultancy Services (−55.6%), Qualcomm (−51.8%), LTIMindtree (−47.6%) and HCL America (−44.0%). Infosys went the other way, up 17.9%. The largest rise was at Nvidia, up 71.2% to 2,390, making it the 15th-largest filer so far this year. Grandison Management rose 37.4%. More than half of its FY2025 filings (54.2%) were for physical therapists, with a median offered wage of $77,480. The big filers aren't all in tech.

Most sponsors are small

The ten largest filers accounted for 15.7% of certified LCAs in FY2025. The top 100 accounted for 34.0%, and the top 1,000 for 55.5%. At the other end, 32,765 employers filed exactly one certified LCA. Including those that filed two, that's 43,454 employers, or 68.4% of all sponsors, together accounting for 10.0% of filings. The median sponsor filed one.

For job seekers, this means a company's absence from the top-100 lists doesn't show it won't sponsor. Most sponsors have never been on those lists.

Volume and pay by type of employer

To compare kinds of employer, we sorted them into groups. Four groups are lists of named employers we chose by hand. The other two are matched by name: any employer with "university" or "college" in its name, and any with "hospital", "medical center", "health system", "clinic" or "children's". Both methods are crude, and the full lists are in the analysis script.

Group (FY2025)	Employers	Certified LCAs	Share	Median offered wage	Oct–Jun change FY25→FY26	PERM per 100 LCAs
Big tech (named list)	23	73,351	13.5%	$169,000	−6.3%	17.2
IT services & outsourcing (named list)	20	47,274	8.7%	$104,728	−31.9%	8.1
Universities & colleges (by name)	1,325	25,953	4.8%	$81,100	−5.4%	9.9
Big Four & strategy consulting (named list)	8	18,899	3.5%	$141,000	−27.7%	6.3
Banks & card issuers (named list)	11	11,949	2.2%	$150,000	−4.3%	15.6
Hospitals & clinics (by name)	1,152	9,099	1.7%	$86,080	−6.8%	11.8
Everyone else	61,006	355,072	65.6%	$114,213	−4.7%	28.7

PERM per 100 LCAs uses FY2024 + FY2025 for both counts.

Two groups account for most of this year's fall. The 20 IT-services firms filed 11,776 fewer certified LCAs in October–June than a year earlier, 33.2% of the total decline. The Big Four and two strategy firms filed 4,356 fewer, 12.3% of the decline. Both shares are far larger than the groups' share of filings. The 61,006 employers in "everyone else" fell by 4.7%.

Universities filed 18.7% more LCAs in FY2025 than in FY2024. Their median offered wage, $81,100, is the lowest of any group, because their most common titles are assistant professor and postdoctoral researcher. Most universities, and the non-profit research bodies linked to them, are exempt from the annual H-1B cap.

What the wages say

These are offered wages: the lower end of the range written on the form, converted to a yearly figure. The job title "Software Engineer" alone had 28,123 certified LCAs from 4,588 employers in FY2025, with a median of $139,000. Across all software-engineer and software-developer titles, there were 105,098 filings with a median of $137,500. The median at each large filer varies far more than that single figure suggests:

Employer	Software-engineer filings	25th pct	Median	75th pct
Salesforce	1,082	$178,743	$211,686	$243,862
Meta Platforms	3,670	$182,000	$203,350	$226,485
Google	5,604	$162,000	$186,000	$200,000
Microsoft	5,700	$153,700	$171,258	$191,461
Amazon.com Services	3,632	$137,259	$160,000	$180,710
JPMorgan Chase	1,886	$140,650	$156,200	$175,000
Walmart Associates	2,366	$120,000	$141,751	$153,301
Tata Consultancy Services	320	$105,997	$112,986	$127,504
UST Global	394	$95,040	$106,866	$121,541

FY2025 certified LCAs whose title contains "software engineer", "software developer", "software development engineer" or "software engineering", or "SDE". Employers with at least 300 such filings with a wage; the full list of 38 is in the script output.

Titles are less useful than they look at the largest outsourcing firms. At Cognizant, 35.2% of FY2025 filings carry one internal job code, "Manager JC50 - Computer Systems Engineers/Architects". At TCS, 40.9% are simply "Architect", with a median of $84,115. Comparing roles across those firms is close to impossible.

To find the best-paid jobs that many employers sponsor, we kept only titles with at least 500 FY2025 filings from at least 25 different employers. The top title wasn't in tech:

Job title	Certified LCAs	Employers	Median offered wage
Hospitalist	673	216	$275,000
Senior Manager	814	94	$198,511
Software Development Engineer III	769	27	$198,000
Engineering Manager	561	292	$196,888
Staff Software Engineer	1,901	443	$177,437

The lowest-paid common titles were teacher ($53,600), market research analyst ($62,900), medical technologist ($63,149) and the various postdoctoral titles ($65,000–$69,926).

Who also sponsors green cards

An LCA supports a temporary visa. PERM labor certification is usually the first step toward an employer-sponsored green card. Dividing PERM certifications by LCAs gives a rough measure of how often an employer takes that second step. Across all employers in FY2024–FY2025, the figure was 23 per 100. For the biggest filers (at least 3,000 certified LCAs), it ranged from 32 down to almost none:

Employer	Certified LCAs FY24–25	PERM certified FY24–25	PERM per 100 LCAs	PERM by year: FY24 / FY25 / FY26 to June
Intel	6,524	2,083	31.9	1,148 / 935 / 326
Apple	9,743	2,645	27.1	1,421 / 1,224 / 33
Nvidia	3,185	853	26.8	280 / 573 / 722
Microsoft	18,706	4,660	24.9	1,734 / 2,926 / 1,600
Google	17,615	1,607	9.1	1,607 / 0 / 1
Amazon.com Services	30,077	2,130	7.1	2,129 / 1 / 56
Cognizant Technology Solutions US	22,316	1,235	5.5	1,235 / 0 / 0
Ernst & Young U.S.	19,429	281	1.4	1 / 280 / 568
Infosys	11,653	87	0.7	87 / 0 / 0

The yearly column shows something the ratio hides. Monthly certifications stopped at several large filers. Google's last month with 50 or more was February 2024, and it has had three in the 28 months since. Amazon.com Services fell below five a month from May 2024 to February 2026 and has risen slowly since (56 in October–June). Cognizant has had none since July 2024 and Infosys none since January 2024. Because PERM cases take more than a year to decide, a decision gap from 2024 points to a pause in filings around 2023, which matches what Google and Amazon were widely reported to have done that year. The data shows only the gap, not its cause.

One warning about this measure: a company may file its LCAs under one legal entity and its PERM cases under another. Fidelity Technology Group has 3,847 LCAs and no PERM cases, while FMR LLC, another Fidelity entity, has 778 PERM certifications in FY2024–FY2025. Check every entity a company uses before concluding that it doesn't sponsor green cards.

Where the jobs are

California accounted for 18.7% of FY2025 certified LCAs by worksite, followed by Texas (15.3%), New York (8.3%), Washington (6.3%) and New Jersey (5.0%). Together those five states had 53.6% of filings.

Why denials tell you nothing

In FY2025, 3,918 LCAs were denied, against 541,597 certified and 31,083 certified then withdrawn. That's a denial rate of 0.68%, and it has been under 1% in each year of the data. An LCA is a statement by the employer: that it will pay at least the required wage, and that hiring the worker won't harm the working conditions of other employees at the site. The Labor Department mostly checks that the form is complete and free of obvious errors. It doesn't decide whether the worker qualifies or whether the job is real. United States Citizenship and Immigration Services (USCIS) decides that later, when it reviews the petition. PERM is checked more closely, and its denial rate was 1.78% in FY2025. Neither rate tells you about visa approvals.

Methodology and caveats

Source. US Department of Labor, Office of Foreign Labor Certification (OFLC), LCA and PERM disclosure files for FY2024 to FY2026 Q3 (1 October 2023 to 30 June 2026). The data is public domain. We are not affiliated with the Labor Department.
Counting. Every file was loaded and de-duplicated by case number, keeping the latest decision. Cases are counted in the fiscal year of the decision date. "Certified" excludes certified-then-withdrawn cases. FY2026 covers only nine months, so it is compared only with the same nine months of earlier years.
A certified LCA is not a visa. One worker can have several LCAs (for example, for a new worksite or an extension), and many LCAs never lead to a petition. LCA counts measure employer filing activity, not people hired or visas approved.
Offered wage is not pay. We use the lower end of any wage range on the form, converted to a yearly figure (2,080 hours a year for hourly wages), and drop values below $10,000 or above $2 million. Bonuses and equity aren't included.
Employers are legal entities. Names are normalised, so "Google LLC" and "GOOGLE LLC" count as one employer. Separate entities of the same company are not merged, apart from the Amazon total we give above. Groups are our own choices, and the lists are in the script.
Privacy. Only business fields are read: status, dates, visa class, employer, job title, wage, worksite state and number of positions. No information about workers, employer contacts, attorneys or form preparers is read or published, and employers that file under a person's own name are excluded.
Reproducible. Two Node.js scripts produce every figure here: one re-reads the DOL files and the other computes the results (results.json). Their case counts match our published employer index exactly (1,570,055 LCA and 373,878 PERM cases).

Nothing here is legal or immigration advice. For your own case, talk to a qualified immigration attorney.

Source: US Department of Labor, Office of Foreign Labor Certification, LCA and PERM disclosure data (public domain).

Each of the 2,000 largest sponsors has a free page at locaihost.org/visa-sponsors/employers/ showing its filings by year, the titles it sponsors and the wages it filed. For example, see Cognizant or Google. To look up many companies at once, or to check live job listings for sponsorship evidence, the same data is available through an Apify Actor at $5 per 1,000 results.

Designing Apify Actors that AI agents actually pick (and can afford)

locaihost data — Sat, 10 Oct 2026 13:21:05 +0000

Most Apify Actors are built for a person who opens the Store page, reads the README, fills in a form and clicks Start. That person can scroll, guess and retry when something goes wrong.

More and more callers are no longer people. An agent in Claude, Cursor or a custom loop connects to the Apify MCP server, searches the Store, reads one short card about your Actor, builds a JSON input from your input schema and runs it with a spending cap. It never sees your README screenshots. It can't ask what "Max results" means. If the run fails, it may simply move on to someone else's Actor.

I'm Ryan Low. I publish pay-per-event Actors on the Apify Store as locaihost: SEC EDGAR financials and insider trades, careers-page jobs from Greenhouse/Lever/Ashby/Personio/Teamtailor, UK/EU/Canada government tenders, and a couple of others. This post walks through one real agent call against my SEC EDGAR Actor, then the design decisions that make an Actor usable (and affordable) for an agent. All the code below is from the Actors as they ship. I've left out anything I haven't measured myself.

1. Setup: one command

Apify hosts an MCP server. In Claude Code you add it with a single command:

claude mcp add apify https://mcp.apify.com/ -t http

The first time you use it, a browser OAuth flow opens and asks you to sign in to Apify, so there is no token to paste. After that the agent has tools such as search-actors, fetch-actor-details, call-actor and get-dataset-items.

To pin an agent to specific Actors, you can pass them in the URL instead (https://mcp.apify.com?tools=locaihost/sec-edgar,...). Each listed Actor then appears as its own tool.

2. What the agent actually sees

Before writing anything for agents, I read the source of apify-mcp-server. Three findings shaped everything else:

search-actors is a thin wrapper over the Store search API (GET /v2/store?search=...). The MCP server does no re-ranking of its own, so agent ranking is Store ranking: relevance plus the quality and popularity signals Apify uses for the Store (reliability, usage, reviews and so on).
The default limit is 5. Agents are told to search with 1–3 keywords like "SEC filings" or "insider trades". Only five cards come back.
The card is built from your Actor's description, verbatim, plus the input field list. Whatever you wrote in description in .actor/actor.json is the pitch an agent reads.

I need to be honest about the first two points. My Actors are a few weeks old, with almost no usage. When I ran agent-style queries against the Store API, none of them appeared in the top 5 for any query I tested. A brand-new Actor will not get picked through search-actors no matter how clean its schema is. Usage builds rank, and rank builds usage, and there's no shortcut I've found.

So why bother? Because search is only one way in. An agent can still reach a new Actor when:

the user names it ("use locaihost/sec-edgar"),
it is pinned in the MCP URL with ?tools=,
it shows up in a README, a blog post or a published task that the user or agent has already read.

In all three cases the agent skips the search and goes straight to fetch-actor-details and call-actor. From there, the input schema, the failure modes and the charge floor decide whether the call works. That part you control on day one.

3. A real call

Here is the call Claude made against locaihost/sec-edgar, via the MCP call-actor tool, when I asked for NVIDIA's recent insider trades:

{
  "actor": "locaihost/sec-edgar",
  "input": {
    "companies": ["NVDA"],
    "modes": ["insiderTrades"],
    "maxResults": 5,
    "onlyNew": false
  },
  "callOptions": {
    "maxTotalChargeUsd": 0.1,
    "memory": 1024
  }
}

The agent made two good choices on its own. It set maxResults to the number of rows it actually needed, and it capped the run's total spend at ten cents with maxTotalChargeUsd. Both of those only work if the Actor respects them, which I come back to below.

The result, abridged:

status:        SUCCEEDED
runtime:       4.24 s
compute units: 0.0012
items:         5
fields (29):   recordType, cik, ticker, companyName, form, filingDate,
               accessionNumber, insiderName, insiderCik, insiderType,
               insiderRole, isDirector, isOfficer, isTenPercentOwner,
               officerTitle, is10b51Plan, securityTitle, transactionDate,
               transactionCode, transactionLabel, acquiredDisposed, shares,
               pricePerShare, value, sharesOwnedAfter, directOrIndirect,
               ownershipNature, filingUrl, scrapedAt

Five rows, each one a Form 4 transaction, in about four seconds. The field names do most of the explaining. An agent working out "who sold, and how much" filters on acquiredDisposed: "D" with transactionCode: "S" and sums value. It doesn't need a README for that.

One field deserves a closer look: insiderName is null for people. Form 4 filings name the individual filer, but the Actor deliberately never outputs a natural person's name. An insider is identified by role (insiderRole: "Officer (CFO)", isDirector, isTenPercentOwner). Names are output only for organisations such as funds, LLCs and holding companies:

// Legal-entity markers. A name matching none of these is treated as a person and is never output.
export const isEntityName = (name: string): boolean =>
    ENTITY.test(name.trim()) && !/\b(FAMILY|REVOCABLE|IRREVOCABLE|LIVING)\b/i.test(name);

// ...inside toTradeRecords():
const entities = owners.filter((o) => isEntityName(o.name));
insiderName: entities.length ? entities.map((o) => o.name).join('; ') : null,
insiderType: entities.length === owners.length && owners.length ? 'entity' : entities.length ? 'mixed' : 'individual',
insiderRole: owners.map(roleLabel).filter(Boolean).join('; '),

Family and revocable trusts count as people. Reporting-owner addresses are never read at all. For agents this matters more than for human users: an agent will happily copy whatever you return into a CRM, an email or a report. If personal data is never in the dataset, it can never leak from there. I made "business data only" a hard rule for all my Actors (I'm in Singapore, and PDPA is the obvious concern). For insider trading analysis, role and size are what you need anyway.

4. Input schema: one obvious required field

The input schema becomes the agent's tool definition. Mine has eleven fields, but an agent only has to understand one:

"companies": {
    "title": "Companies",
    "type": "array",
    "description": "One per line: a US ticker (AAPL, BRK.B), an SEC CIK number (320193) or a company name (Microsoft). Any company that files with the SEC. Up to 500.",
    "editor": "stringList",
    "prefill": ["AAPL", "MSFT", "NVDA"]
}
// ...
"required": ["companies"]

Every other field has a sensible default: all three modes, the last 90 days, 8 periods, newest filings first. A minimal valid call is {"companies": ["NVDA"]}.

Note the prefill, not default, on the required field. This is the easiest trap to fall into. A required field that also has a default silently loses its required flag in the tool schema the agent receives. To the agent, the field looks optional. It then calls the Actor without it, the platform fills in your default, and the agent gets data for AAPL, MSFT and NVDA when it asked about something else. prefill fills in the form for humans in the console and still shows an example value, but required survives. Apify's own write-up on making Actors visible to agents puts it bluntly: a required field with a default is always a bug.

A few smaller rules I follow in every schema:

Descriptions under 500 characters. Field and Actor descriptions end up in the tool definition and the search card. Long ones get truncated or eat the agent's context. Put the essentials first: what to type, in what format, with one example.
Accept what a model is likely to send. companies takes tickers, CIKs or names. sinceDate takes 2026-07-01 or "90 days" or "6 months". A model will try the natural phrasing first, so treat it as valid.
Arrays stay arrays. modes is an enum array with enumTitles, not a comma-separated string the agent has to guess the format of.

5. Bad input should not mean FAILED

What should happen when an agent sends {"companies": ["NVIDIAA"]}, or a list where every entry is junk?

My first versions called Actor.fail() with a clear message. That seemed right until I ran a robustness pass and noticed two problems. A FAILED run counts against the Actor's success rate, which feeds the quality score, which feeds search rank (the same rank agents see). And to an agent, FAILED looks like "this tool is broken", not "you sent a bad ticker".

So invalid input now ends SUCCEEDED, with nothing charged and a message that says how to fix it:

if (unresolved.length) log.warning(`Not found on EDGAR (use the ticker or CIK): ${unresolved.join(', ')}`);
if (!refs.length) {
    // Unknown tickers are an input problem, not a crash: exit SUCCEEDED with nothing charged.
    await Actor.setValue('SUMMARY', { since, modes: [...modes], pushed: 0, notFound: unresolved, companies: [] });
    await Actor.exit(`No companies to look up${unresolved.length ? ` — not found on EDGAR: ${unresolved.slice(0, 20).join(', ')}` : ''}. Add tickers (AAPL), CIKs (320193) or company names (Microsoft).`);
}

The exit message becomes the run's status message, which is part of the run details an agent can read back. An agent that reads "not found on EDGAR: NVIDIAA. Add tickers (AAPL)…" corrects itself on the next call. Actor.fail() is kept for real failures only: if every company lookup hit an upstream error, the run fails, because then something really is broken.

The careers-jobs Actor goes one step further and rejects junk before fetching anything (sentences, markup, 300-character pastes), so prompt-injected garbage in the companies array never turns into outbound requests or charges.

6. Pay-per-event charging you can trust

All my Actors use pay-per-event pricing: a tiny start fee plus one event per record. For sec-edgar that's $2 per 1,000 records at the base tier, so the five-row NVIDIA call above cost about a cent. Agents work well with this model: they pay for exactly what they used, and maxTotalChargeUsd gives them a hard ceiling.

There is a catch in the SDK. Under pay-per-event, Actor.pushData(items, eventName) returns a ChargeResult telling you how many items were charged, and therefore stored. When the user's charge limit is reached mid-batch, the SDK drops the rest. My Actors batch pushes (100 items per API call), and for batches the returned ChargeResult can undercount or overcount. I don't fully understand why, though the client chunking requests internally is the likely cause. That matters because my "only new since last run" mode remembers which items were delivered. Trust a wrong count, and a user either pays for an item they never got or never sees it again.

The fix is to stop trusting the return value and measure the charging manager's counter before and after. This is the actual push function from the careers-jobs Actor (sec-edgar uses the same one with EVENT = 'record'):

// Measure the charged-event counter delta; the per-call ChargeResult is unreliable for batches.
const charging = Actor.getChargingManager();
const isPpe = charging.getPricingInfo().isPayPerEvent;
const emitter = new BatchEmitter<Job>(
    async (items) => {
        if (!isPpe) {
            await Actor.pushData(items);
            return undefined;
        }
        const before = charging.getChargedEventCount(EVENT);
        await Actor.pushData(items, EVENT);
        return {
            chargedCount: charging.getChargedEventCount(EVENT) - before,
            eventChargeLimitReached: charging.calculateMaxEventChargeCountWithinLimit(EVENT) <= 0,
        };
    },
    cap,
    (keys) => seenList.push(...keys),
);

The BatchEmitter then treats chargedCount as the truth: only that many items are counted as emitted, only their keys go into the "seen" list, and the run stops cleanly once the limit is hit:

const res = (await this.push(batch.map((b) => b.item))) || {};
const stored = Math.min(res.chargedCount ?? batch.length, batch.length);
this.emitted += stored;
this.onStored(batch.slice(0, stored).map((b) => b.key));
if (res.eventChargeLimitReached || stored < batch.length) this.stopped = true;

So an item dropped by an agent's ten-cent cap is not marked as seen, and it comes back on the next run. Note that the !isPpe branch matters too: outside pay-per-event (local runs, for example) the ChargeResult reports zero charged even though everything was stored.

One more thing to know while testing: a run's chargedEventCounts and the dataset itemCount lag a few seconds behind the end of the run. Re-fetch before deciding you've found a billing bug.

7. Let small budgets in

Pay-per-event Actors have a pricing setting called minimalMaxTotalChargeUsd. It's the lowest maxTotalChargeUsd a caller may set when starting a run. If an agent's budget is below your floor, the run doesn't start.

Agents tend to use small budgets on purpose. Claude chose $0.10 for a five-row lookup, which is a sensible thing for an agent to do. A floor of a dollar would have blocked that call. When I repriced my Actors I lowered the floor to $0.05 on all of them.

"minimalMaxTotalChargeUsd": 0.05

Two related details. First, when changing pay-per-event pricing through the API, you append a new pricingInfos entry; replacing the existing ones fails. Second, the default run memory is set to 1 GB in actor.json, because the Actor-start event is charged per GB of memory. Agents rarely override memory, so whatever default you pick is what they pay.

8. Other guardrails worth having

A free-plan cap that's documented. On Apify's free plan my Actors return at most 100 records per run, and the run log says so. An agent that sees 100 rows and a warning can explain the reason to the user instead of guessing.
Respect upstream limits. sec-edgar sends every request through one global rate limiter (8 requests per second, under SEC's fair-access limit), with a declared User-Agent and backoff when SEC throttles. Agents run in loops; your Actor should not let a loop hammer the source.
Official, public sources. EDGAR data is public domain. That's one less thing an agent (or its user) has to worry about before using the output.
A SUMMARY record. Every run writes a SUMMARY key-value record with per-company counts, notes and "not found" lists. An agent that gets zero rows can read why.

Checklist

If you want an agent to be able to use your Actor, and afford it:

[ ] Actor description starts with a verb, says what comes back, and stays under 500 characters. It is the agent's tool card.
[ ] One obvious required field, with prefill and no default. Everything else optional with sensible defaults.
[ ] Field descriptions under 500 characters, essentials first, one example each.
[ ] Accept the natural formats a model will try (tickers and names, "90 days" and ISO dates).
[ ] Invalid input ends SUCCEEDED, charges nothing and says how to fix it. Actor.fail() only for real outages.
[ ] Honour maxResults and the caller's maxTotalChargeUsd, and stop cleanly when either is reached.
[ ] Count charges with getChargedEventCount() deltas, not the batched pushData ChargeResult.
[ ] minimalMaxTotalChargeUsd low enough for small agent budgets (I use $0.05).
[ ] No personal data in the output. Identify people by role, not name.
[ ] Expect search-actors to ignore you at first. Get in front of agents through names, ?tools= URLs, READMEs and published tasks while usage builds.

None of this makes a new Actor show up in an agent's top five. That takes usage, and I don't have much yet. What it does is make sure that when an agent does reach your Actor, the first call works, costs what it should, and gives the agent something it can use.

More about what I'm building is at locaihost.org.