Company Tech Stack Changes & Migration Monitor

Know when a target company changes its technology stack

Monitor up to 100 company domains and detect meaningful public technology changes over time.

The Actor watches public homepage resources, HTTP response headers, structural framework markers, and public DNS MX records to identify signals such as:

• STACK_ADDED — a detected technology appears that was not present in the previous healthy baseline;
• STACK_REMOVED — a previously detected technology is no longer present;
• MX_PROVIDER_CHANGE — the detected email/MX provider changes.

The default monitor mode stores the first healthy baseline for free and, on later runs, writes only change events plus one free RUN_SUMMARY.

A separate snapshot mode exports the full currently detected stack for each domain.

No login. No browser automation. No vendor API keys. No LLM.

Key features

• Monitor up to 100 domains per run
• Detect technologies added
• Detect technologies removed
• Detect MX/email-provider changes
• Change-only monitor mode
• One-shot full stack snapshot mode
• Free first-run baseline
• Free RUN_SUMMARY on every monitor run
• Versioned signature library
• Suppression of unsafe removal events after signature-library changes
• Degraded-detection protection
• Per-domain robots.txt handling
• Public DNS MX enrichment
• Persistent per-domain state
• Schedule-ready for recurring B2B monitoring
• Pay only for change events or snapshot records actually written

Unofficial community Actor. Not affiliated with, sponsored by, or endorsed by any technology vendor detected. Detection is based on evidence visible in public website resources, public HTTP response headers, structural markers, and public DNS.

---

What makes this Actor different

This is not just a one-time technology detector.

The primary product is change detection.

Instead of repeatedly exporting the same technology list, monitor mode answers questions such as:

Which of my target companies changed their public tech stack this week?

Who started loading a tool in my category?

Which domains stopped exposing a previously detected technology?

Which companies changed their public MX/email provider?

This makes the Actor useful for recurring:

• B2B sales signals;
• account research;
• partner intelligence;
• competitive intelligence;
• migration monitoring;
• agency prospecting;
• market research.

---

Important detection philosophy

Loaded evidence, not text mentions

A technology signature only fires when there is actual technical evidence.

Examples include:

• a script, link, iframe, or img resource URL matching a known vendor delivery domain;
• an HTTP response header identifying infrastructure or hosting;
• a structural framework marker such as __NEXT_DATA__ or ng-version.

A webpage merely mentioning a vendor name in visible text does not count as detection.

For example, a blog article discussing HubSpot or Marketo does not produce a detection unless the page actually exposes matching technical evidence.

This strict approach intentionally favors precision over maximum coverage.

A false positive in monitor mode could become a false paid change event, so the Actor does not guess.

---

Who it's for

B2B sales and SDR teams

Monitor target accounts for technology changes that may create a reason to investigate or reach out.

Example:

"Which of my 80 target accounts changed their public stack this week?"

Possible signals include:

• adoption of a marketing platform;
• disappearance of a detected tool;
• an email-provider migration;
• an infrastructure or framework change.

A technology change is a signal for further research, not proof of purchase intent.

Agencies and consultants

Watch prospect or client domains for migrations that may create implementation, integration, migration, optimization, or support work.

Competitive intelligence teams

Track which monitored companies begin or stop exposing technologies in a category.

Partnerships and ecosystem teams

Watch selected companies for adoption of technologies relevant to integrations, partnerships, or ecosystem strategy.

Market researchers

Export one-time snapshots or recurring change events across a defined domain list.

---

Two operating modes

The Actor supports:

monitor
snapshot

---

Monitor mode

monitor is the default mode.

First healthy run

For each domain, the Actor stores a baseline in the persistent state store.

The initial baseline does not create fake STACK_ADDED events for every technology already present.

The monitor establishes what is currently detected and stores that state for comparison with future runs.

Every monitor run also writes one free:

RUN_SUMMARY

record.

So a valid run with no changes still produces a non-empty dataset confirming what was monitored.

Example interpretation:

80 domains monitored
0 change events
1 RUN_SUMMARY

Later healthy runs

The Actor compares the current detected state against the previous healthy state and writes one record per selected change event.

Possible event types:

STACK_ADDED
STACK_REMOVED
MX_PROVIDER_CHANGE

---

Snapshot mode

snapshot is a one-time export mode.

Instead of writing only changes, it writes one:

DOMAIN_RESULT

record per successfully processed domain.

Snapshot records contain the currently detected stack and available domain-level metadata.

Use snapshot mode for:

• initial tech-stack research;
• one-time domain enrichment;
• portfolio analysis;
• technology inventory;
• downstream comparison in your own system.

---

Input

Basic monitor example:

{
  "domains": [
    "stripe.com",
    "hubspot.com"
  ],
  "mode": "monitor"
}

Input fields

Field	Type	Default	Description
domains	array	required	1–100 domains or URLs. Protocol, www, and paths are normalized away.
mode	string	monitor	monitor for baselines + change events + free summary, or snapshot for a one-time full detected-stack export.
eventTypes	array	all 3	Select from STACK_ADDED, STACK_REMOVED, and MX_PROVIDER_CHANGE.
maxResults	integer	5000	Hard cap on charged records. If the cap truncates a domain, that domain's stored state is not advanced.
requestDelayMs	integer	500	Deliberate pacing per request. Minimum accepted value is 250 ms.

---

Example: monitor only additions

{
  "domains": [
    "example.com",
    "example.org"
  ],
  "mode": "monitor",
  "eventTypes": ["STACK_ADDED"]
}

---

Example: monitor additions and MX changes

{
  "domains": [
    "example.com",
    "example.org"
  ],
  "mode": "monitor",
  "eventTypes": [
    "STACK_ADDED",
    "MX_PROVIDER_CHANGE"
  ]
}

---

Example: one-time snapshot

{
  "domains": [
    "stripe.com",
    "hubspot.com"
  ],
  "mode": "snapshot"
}

---

Change-event output

Monitor mode writes:

CHANGE_EVENT

records.

Example:

{
  "recordType": "CHANGE_EVENT",
  "eventType": "STACK_ADDED",
  "domain": "gymshark.com",
  "signatureKey": "klaviyo",
  "signatureLabel": "Klaviyo",
  "category": "marketing",
  "signaturesVersion": "2026-07-30.1",
  "previousCheckedAt": "2026-07-23T06:00:00.000Z",
  "detectedAt": "2026-07-30T06:00:00.000Z"
}

Main event concepts

Field	Description
recordType	CHANGE_EVENT for monitor change records.
eventType	STACK_ADDED, STACK_REMOVED, or MX_PROVIDER_CHANGE.
domain	Normalized monitored domain.
signatureKey	Stable internal technology signature key when applicable.
signatureLabel	Human-readable detected technology label when applicable.
category	Technology category when applicable.
signaturesVersion	Version of the detection signature library used for the record.
previousCheckedAt	Timestamp of the previous healthy comparison state.
detectedAt	Timestamp of the current detection.

MX-provider change events use the applicable previous/current provider information in their normalized event record.

---

Snapshot output

Snapshot mode writes:

DOMAIN_RESULT

records.

A domain snapshot can include:

• full detected stack[];
• technology labels;
• technology categories;
• mxProvider;
• mxRecords;
• page title;
• meta description;
• resourcesScanned;
• signature-library version;
• extraction timestamps and status metadata.

Snapshot mode is a technology and public-domain metadata export.

It should not be interpreted as full business firmographics such as employee count, revenue, funding, headquarters, or industry unless those fields are explicitly added in a future version.

---

Technology detection sources

The Actor currently uses public evidence from:

Homepage resource URLs

Supported evidence includes statically visible resource references such as:

script
link
iframe
img

A vendor can be detected when one of those resource URLs matches a curated signature.

HTTP response headers

Headers can expose technologies related to:

• hosting;
• CDN;
• platform infrastructure.

Structural framework markers

Examples include:

__NEXT_DATA__
ng-version

Public DNS MX records

The Actor performs MX lookup through public DNS-over-HTTPS and maps recognized providers when possible.

---

Strict detection means documented false negatives are possible

The Actor deliberately does not claim complete technology coverage.

A technology may be missed when it is:

• injected only at runtime through inline JavaScript;
• loaded only after user interaction;
• injected exclusively through a tag manager;
• present only on a checkout flow;
• present only on a subdomain;
• present only behind authentication;
• absent from the homepage;
• delivered through a pattern not yet covered by the signature library.

This is a conscious precision tradeoff.

The Actor would rather miss a technology than generate an unsupported paid STACK_ADDED event.

---

Versioned signature library

The detection signature library is versioned.

Each relevant record carries:

signaturesVersion

Technology delivery patterns change over time, so the signature library can evolve.

Removal protection after a signature update

A signature-library change can make an older signature disappear even when the customer did not actually remove the technology.

To avoid turning a detector update into a false:

STACK_REMOVED

signal, removal events are suppressed for a run when the signature-library version changes between comparison states.

This prevents detector-maintenance changes from being presented as customer behavior.

---

Degraded-detection protection

A suspicious or incomplete homepage response should not cause a wave of false removal events.

If the current response appears degraded — for example:

• the returned page is implausibly small;
• the site exposes zero technologies even though a healthy previous state contained signatures;
• the content resembles a challenge or error response;

the domain can be marked:

DETECTION_DEGRADED

In that condition:

• no change events are emitted for the degraded comparison;
• the previous healthy state is preserved;
• the stored state is not replaced by suspicious empty detection.

The next healthy run can therefore compare against real historical state.

---

robots.txt handling

The Actor checks:

robots.txt

before fetching the homepage.

A domain that explicitly blocks all access for:

User-agent: *
Disallow: /

is skipped with a controlled status:

DOMAIN_ROBOTS_DISALLOWED

The homepage is not fetched in that condition.

---

Block handling

A blocked domain can receive:

DOMAIN_BLOCKED

The Actor does not use browser automation, proxy rotation, login, or access-control bypass to evade a blocked public response.

---

MX provider monitoring

The Actor performs a public MX lookup for each processed domain.

When a recognized provider changes between healthy monitor states, the Actor can create:

MX_PROVIDER_CHANGE

Example conceptual signal:

Google Workspace → Microsoft 365

MX detection is enrichment, not a guarantee.

A DNS lookup failure results in unavailable MX data rather than an invented provider change.

A provider outside the recognized mapping can appear as:

other

---

Run summary

Every valid monitor run writes one free:

RUN_SUMMARY

record.

The summary provides run-level visibility even when there are zero change events.

It can report information such as:

• domains monitored;
• domains skipped;
• per-domain statuses;
• current detected stack size;
• MX result;
• event counts;
• degraded detections;
• suppressed events;
• warnings.

The free summary does not count as a charged change event.

---

STATS and diagnostics

Operational details are stored in:

STATS

and failures can be stored in:

ERRORS

STATS includes information such as:

• per-domain status;
• detected stack size;
• MX provider;
• events produced;
• HTTP counters;
• degraded-detection counters;
• suppressed-event counters;
• field-completeness checks;
• warnings.

---

Persistent monitor state

Monitor state is stored in the named key-value store:

COMPANY-STACK-STATE

with one state key per domain.

This state provides the baseline used for future diffs.

Force a fresh baseline

Delete a domain's state key from:

COMPANY-STACK-STATE

to make the next healthy monitor run establish a new baseline for that domain.

Use this deliberately because resetting state removes the previous comparison history for that domain.

---

Result-cap safety

maxResults limits charged records.

If the output cap is reached in a way that truncates a domain's event set, that domain's state is not advanced.

This prevents the stored baseline from moving forward when not all detected changes were actually written.

---

Scheduling

Tech-stack changes are most useful as a recurring signal.

Use Apify Schedules to run the Actor automatically in the cloud.

Recommended workflow

1. Save your domain list as an Apify Task.
2. Run the first healthy execution to establish baselines.
3. Go to Console → Schedules → Create schedule.
4. Add the saved Task.
5. Choose a recurring cadence.
6. Send new change events into your downstream workflow.

A weekly schedule is a practical starting point for many account-monitoring use cases.

Example Monday 6:00 AM cron:

0 6 * * 1

Possible destinations include:

• Slack;
• Google Sheets;
• CRM systems;
• databases;
• webhooks;
• internal dashboards;
• sales-intelligence workflows.

---

Example B2B monitoring workflow

Input:

{
  "domains": [
    "company-one.com",
    "company-two.com",
    "company-three.com"
  ],
  "mode": "monitor"
}

First run

The Actor:

• processes the selected domains;
• stores healthy baselines;
• writes the free run summary;
• does not pretend that all currently detected technologies are newly adopted.

Later run

Suppose one domain:

• starts exposing a new recognized marketing technology;
• stops exposing another technology;
• changes its recognized MX provider.

The Actor can write the corresponding selected events:

STACK_ADDED
STACK_REMOVED
MX_PROVIDER_CHANGE

The dataset can then be routed to your CRM, Slack channel, database, or another automation.

---

Pay only for written events or snapshots

This Actor uses Pay Per Event pricing.

You are charged for:

• change-event records written in monitor mode;
• domain snapshot records written in snapshot mode.

The monitor baseline and free RUN_SUMMARY do not become charged change events.

Records not written because of filters or output caps are not billed as result events.

The Pricing tab on the Actor page is always the authoritative source for current prices and any run-start fee.

---

Request footprint

A healthy domain run can involve up to approximately three public requests/queries:

1. robots.txt;
2. homepage;
3. public DNS MX lookup.

The Actor uses deliberate pacing controlled by:

requestDelayMs

Default:

500

Minimum:

250

---

What this Actor does not do

This Actor does not:

• perform a deep website crawl;
• scan every page of a domain;
• crawl checkout flows;
• access logged-in areas;
• use browser automation;
• execute a full client-side browsing session;
• use vendor accounts or API keys;
• use an LLM to guess technologies;
• infer technologies from plain-text mentions;
• bypass a site-wide robots disallow;
• evade blocked responses;
• provide BuiltWith-scale technology coverage;
• provide complete company firmographics.

---

Honest limits

Homepage only

The detector analyzes the public homepage rather than deeply crawling the entire site.

A technology used only on another page may not be detected.

Static evidence only

Tools injected entirely at runtime through inline JavaScript may not expose a static resource signature in the fetched homepage HTML.

This can produce a false negative.

Best-effort signature coverage

The Actor currently uses a curated and evolving signature library across areas such as:

• e-commerce;
• CMS;
• marketing and CRM;
• support;
• analytics;
• payments;
• frameworks;
• CDN and hosting.

The library is not intended to represent every technology on the web.

Vendor delivery patterns can change

Technology vendors can change:

• script domains;
• CDN paths;
• resource structures;
• headers;
• integration patterns.

That is why signaturesVersion is preserved and removal protection exists after library changes.

MX provider detection is best-effort

DNS errors can make the provider unavailable.

Unknown providers can be classified as:

other

rather than guessed.

No deep firmographics in this version

Snapshot mode includes public website metadata and detected-stack information.

It does not currently claim fields such as:

• employee count;
• annual revenue;
• funding;
• headquarters;
• industry taxonomy.

Public websites change over time

Homepage structure, headers, DNS records, and technology delivery methods can all change.

---

FAQ

Do I need an account or API key for detected vendors?

No.

The Actor works from public website and DNS evidence.

Does it use Wappalyzer or BuiltWith?

The Actor uses its own curated, versioned signature library and documented evidence rules.

It should not be presented as equivalent in detection breadth to large commercial technology-intelligence datasets.

Does it crawl the whole website?

No.

Technology detection is based on the public homepage, response headers, structural markers, and public MX records.

Why did it miss a technology I know the company uses?

Possible reasons include:

• the tool is not exposed on the homepage;
• it is loaded only after runtime JavaScript execution;
• it is injected through a tag manager;
• it is used only on checkout;
• it exists only on a subdomain;
• it requires authentication;
• its delivery pattern is not yet covered by the signature library.

The Actor intentionally does not guess.

Can it produce false removals if the detector signatures change?

The Actor is designed to reduce that risk.

When signaturesVersion changes between runs, removal events are suppressed for that comparison run.

What happens when a page response looks broken?

The domain can be marked:

DETECTION_DEGRADED

The Actor does not emit changes from the suspicious comparison and preserves the previous healthy state.

What happens if robots.txt disallows the whole site?

The domain is skipped with:

DOMAIN_ROBOTS_DISALLOWED

What happens if a domain blocks the request?

It can receive:

DOMAIN_BLOCKED

The Actor does not attempt to evade the block.

Can I detect only additions?

Yes.

Set:

{
  "eventTypes": ["STACK_ADDED"]
}

Can I export the full detected technology stack?

Yes.

Use:

{
  "mode": "snapshot"
}

What is the difference between monitor and snapshot?

monitor stores state and writes change events after the baseline is established.

snapshot writes the full currently detected state as a one-time domain result.

What is RUN_SUMMARY?

A free monitor-run summary record that gives you run visibility even when no change events occurred.

Where is monitor state stored?

In:

COMPANY-STACK-STATE

with one key per domain.

Can I reset a domain baseline?

Yes.

Delete that domain's state key from COMPANY-STACK-STATE.

How many domains can I monitor?

Up to:

100

domains or URLs per run.

Can I schedule it?

Yes.

Recurring monitoring is one of the Actor's primary use cases.

Is a tech-stack change proof that a company is about to buy something?

No.

A stack change can be useful as a sales, migration, market, or research signal, but it does not prove purchasing intent.

Is this affiliated with detected technology vendors?

No.

This is an unofficial community Actor and is not affiliated with, sponsored by, or endorsed by detected vendors.

---

Part of the JM Forge suite

Also from the same developer:

• ATS Hiring Signals — Greenhouse, Lever & Ashby — Monitor recent public job postings across Greenhouse, Lever, and Ashby for hiring signals and account research.

• Google Maps Business Leads Scraper — Extract public Google Maps business data including names, categories, addresses, phones, websites, ratings, coordinates, and result rank.

• Consulta CNPJ Brasil e Empresas por CNAE — Look up Brazilian company registry data by CNPJ in bulk and discover companies by CNAE, state, and city.

Support

Report issues in the Issues tab of this actor — I respond within 24h. Feature requests welcome.