Atlassian & Stripe: Subprocessor Change Monitor avatar

Atlassian & Stripe: Subprocessor Change Monitor

Pricing

from $2.00 / 1,000 scoped-company evidences

Go to Apify Store
Atlassian & Stripe: Subprocessor Change Monitor

Atlassian & Stripe: Subprocessor Change Monitor

Track changes in Atlassian and Stripe subprocessor, service-provider and affiliate tables. Compare supplied snapshots for added, removed and changed entries with before/after evidence and source links. Unofficial; Stripe countries identify entities, not processing locations.

Pricing

from $2.00 / 1,000 scoped-company evidences

Rating

0.0

(0)

Developer

Felix GoldWin

Felix GoldWin

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

10 days ago

Last modified

Categories

Share

Atlassian & Stripe Vendor Change Monitor

Track source-backed changes to the two supported vendors' published organization tables. Each run emits normalized company evidence with exact before/after objects, source links, observation time, and complete-scan diagnostics. Supply a previous SNAPSHOT to compare; no global or cross-user state is used.

Supported coverage

SourceSupported tablesMeaning of location
AtlassianThird-party subprocessors, Government Cloud subprocessors, Atlassian Group subprocessorsPublished processing location, including regions and qualifications
StripeSub-processors, service providers, affiliatesPublished entity country, not proof of processing location

These are bounded source-specific adapters. They do not crawl linked security pages, inaccessible trust centers, arbitrary vendors, or customer accounts. Stripe's table labels remain sub-processors, service providers, and affiliates; they are not relabeled into one legal category. Source cells can list a category or multiple organizations; that exact company-cell text remains one record.

Company identity is the exact normalized company text within its table section/group. The same organization appearing in multiple groups produces separate records. Atlassian rowspan entries and repeated company rows are retained as product/purpose/location entries in their scoped record. A company rename or section move is an added row plus a removed row, not a verified legal-entity change.

This is evidence for human review, not a compliance certification. A listed party may not apply to every customer's services. A removal only means the company text was absent from the same supported page sections; it does not prove the relationship ended. No messages are sent.

Run and compare

{"vendors":["atlassian","stripe"],"maxResults":200,"maxRequests":10,"maxChargeUsd":0.5}

Read the default dataset for baseline, unchanged, added, changed, or removed rows. before and after preserve full normalized table evidence without silent truncation. Whitespace, mobile labels, markup and hyperlink targets are excluded; security-measure links are not tracked. changedFields indicates which normalized fields differ; entries contain products, purpose, location, and personalDataCategories. The latter is a published category description, never individual personal data. Missing cells stay null.

The key-value store OUTPUT records scan completeness, exact source URLs, final same-origin URLs, response SHA-256, source date and its label, request/byte counts, budget, and source limitations. Atlassian publishes an Effective Starting date; Stripe publishes Last updated. Neither is replaced with the retrieval date. A date-only edit appears in diagnostics/snapshot metadata, not as a company change.

Download SNAPSHOT and pass its JSON as previousSnapshot on the next run. It must use the same vendor/parser scope and contain only your own complete snapshots. Caller evidence is structurally validated and explicitly labeled as not independently authenticated. No prior URLs are fetched. Keep the last verified complete snapshot for each vendor if a later scan fails; failed vendors are omitted from the new snapshot. There is no automatic merge with a previous run.

Unknown headers, missing tables, empty groups, malformed spans, duplicate entries, source denials, exceeded bounds, or changed section coverage suppress that vendor's comparison and reusable snapshot. If a legitimate group is added or removed, review and update the parser/scope before establishing a new baseline. A full vendor's rows must fit the result and charge capacity; that vendor is otherwise withheld. Other vendors can still succeed. Always check both complete and each diagnostic's outputComplete.

Bounds and billing

Defaults: 200 dataset rows; 10 HTTP requests including redirects/retries; 120 seconds of source work; 20 seconds/request; 1.5 MB/response; 4 MB total response bodies; 2 retries. Hard maxima: 1,000 rows, 20 requests, 300 seconds source work, 30 seconds/request, 3 MB/response and 6 MB total. Input is capped at 3 MB, reusable snapshots at 2 MB, and each parser at 300 scoped companies, 50 entries/company, and 10,000 characters/cell. Overlong evidence fails instead of truncating. Source work is sequential; SDK initialization and dataset storage add runtime. Set Apify's run timeout and charge limits too.

HTTP 403/401 and other access denials stop; no proxy, login, or bypass is used. At most two redirects are accepted and only to the fixed vendor's approved HTTPS legal-page paths. Retry-After over 10 seconds stops. There is no pagination on these complete HTML tables; table/group validation replaces pagination completeness checks.

User-approved listing pricing, not configured by this source package: automatic apify-actor-start at $0.005 per platform memory unit of up to 1 GB, plus vendor-evidence-row at $0.002 per emitted scoped-company row. Baseline, unchanged, added, changed, and removed rows all count. Multiple entries in a scoped company record do not add charges. This unit pays for the recurring complete table check and preserved comparison evidence; it is not a claim that only changed companies cost work. At the observed 140-row baseline, these rates total approximately $0.285 including one start unit. Pages and row counts change.

Runtime reads actual configured prices, honors both the custom cap (default $0.50) and platform capacity, includes prior charges plus any pending automatic start reservation, and refuses positive synthetic dataset-item charges or unknown paid events to prevent double billing. Automatic starts are never manually charged. A zero custom cap prevents source requests, but cannot refund an already automatic platform start. Outside pay-per-event mode the custom cap does not control platform compute/storage costs. Platform deployment and paid billing remain unverified.

Local development

Node.js 22 or newer:

npm ci --ignore-scripts
npm test
npm run validate:schema
npm run smoke
npm start

smoke makes two bounded public page requests and saves only hashes, counts, source diagnostics and a few normalized rows in artifacts/live-smoke.json; it does not store source HTML. For npm start, place input in storage/key_value_stores/default/INPUT.json. See QA.md, NOTICE.md, and PUBLISHING.md.

Hosted verification update — 2026-10-11 UTC

This update supersedes the original builder-only deployment status above. Apify build 0.0.1 succeeded with Node 22. Two owner-account runs at 256 MB, 180 seconds and a $0.30 platform cap each delivered 140 rows from two HTTP requests: 49 Atlassian and 91 Stripe records. Baseline OUTPUT confirmed both vendors complete, outputComplete and reusable snapshots. The repeat run accepted that snapshot and emitted unchanged observations. Peak memory was 83.3 MB across these small tests. Configured listing prices are $0.005 automatic start per up-to-1-GB unit plus $0.002 per emitted scoped-company row; the synthetic paid dataset event is removed. Baseline and unchanged rows are billable. Customer PPE pricing includes platform usage. Runtime used platform_pay_per_event and verified custom-event count increases per row. Owner usage was $0.001 per run, rounded by Console; this is not a customer invoice test or maximum-load guarantee. The listing is unofficial and is not affiliated with Atlassian or Stripe.