What data can ApifyForge access?

What ApifyForge can access

With the five scoped permissions (Actors: Read, Run, List runs; Storages: Read, Write), ApifyForge can read:

Your actor list and metadata — names, descriptions, pricing model, memory and timeout defaults
Your build history for each actor — version numbers, build timestamps, input/output schemas (read-only)
Run history for every actor — status, duration, memory consumption, cost per run, failure reasons
The contents of datasets, key-value stores, and request queues you own — but see the Honest disclosure section below for the important scope nuance

And with Storages: Write, ApifyForge's backend actors can write:

Actor OUTPUT to the default key-value store of each run ApifyForge triggers on your behalf
Trend snapshots and acknowledgement state, so next week's run can compute week-over-week deltas and regression detection

That is the complete set of what ApifyForge touches on your Apify account.

What ApifyForge cannot access

The scoped token does not grant any access to:

❌ Your actor source code — blocked at the Apify platform level, even for full-access tokens
❌ Environment variables or secrets stored in your actor configuration
❌ Billing information, payment methods, or usage quotas
❌ Proxy passwords, proxy groups, or proxy configuration
❌ The ability to create, delete, or rename actors (Actors: Write is not granted)
❌ The ability to trigger new builds or manage existing builds (Actors: Build is left unchecked)
❌ Webhooks on your actors (both webhook permissions left unchecked)
❌ Apify Tasks — the entire Tasks resource group is unchecked; ApifyForge does not use Tasks at all
❌ The ability to create new storages (Storages: Create is left unchecked; Apify auto-creates default storages per run)
❌ Schedules, user management, or token management
❌ Any data owned by other Apify users — the token is scoped strictly to your own account

Honest disclosure (read this if your data is sensitive)

Apify's permission schema bundles key-value stores, datasets, and request queues together under a single Storages: Read checkbox and does not let you narrow it further. When you grant Storages: Read, the scoped Apify API token can — from an API capability standpoint — fetch the contents of any dataset you own, including datasets produced by your own scrapers that have nothing to do with ApifyForge.

In practice, ApifyForge only reads:

The specific datasets returned by run-sync-get-dataset-items calls initiated by its own backend actors
Specific key-value store keys (like OUTPUT and SIGNALS) that those actors wrote

The row data of your other datasets — the ones your own scrapers produce — is never fetched by the ApifyForge server, never cached in the ApifyForge database, and never persisted anywhere in ApifyForge infrastructure.

Enforcement model. The "we only read our own actors' datasets" guarantee is enforced by ApifyForge's code, not by Apify's permission schema. The only dataset-fetching code paths in apifyforge/src/lib/apify/runner.ts are run-sync-get-dataset-items calls that ApifyForge itself initiated, plus getRunResults lookups for those same run IDs. There is no other dataset-fetching code path. Apify's platform has no per-dataset scoping available in the permission UI, so the technical capability the token grants is wider than the implementation actually uses.

If you consider the contents of your scraped datasets highly sensitive, you should know the scope is wider than "metadata only" and the guarantee is procedural rather than technical. For the strongest isolation, use the CLI flow instead of the browser token flow — the CLI (npx apifyforge run <tool>) keeps the token entirely on your own machine, so there is no server-side copy to exfiltrate. Both flows produce identical analytics in the dashboard.

Risk level summary

ApifyForge data access falls into three risk tiers, from lowest to highest:

🟢 Low risk: metadata and run history access. Actors: Read and Actors: List runs grant read-only access to non-sensitive operational data — actor names, pricing, run status, and cost. A leak of just these permissions would expose operational metadata but no customer data, secrets, or destructive capability.
🟡 Medium risk: storage read access. Storages: Read grants read access to every dataset, key-value store, and request queue you own. In practice ApifyForge only reads datasets it produced, but the token is technically capable of reading all of them. A leak would allow an attacker to read sensitive scraped data if any exists in your account.
🔴 Higher risk: storage write access. Storages: Write is the only genuinely destructive permission in the scoped set. A leaked token could corrupt, overwrite, or delete records in any storage you own. This is the one permission that requires real caution for production accounts.

Overall: moderate risk with strong safeguards when using a scoped Apify API token plus the best practices in Production hardening below. For high-stakes workloads, use the CLI flow instead — it keeps the token entirely on your own machine.

What each scoped permission grants

The scoped token grants exactly five permissions. Here is what each one unlocks, and nothing more.

Actors: Read

What it grants. GET /v2/acts, GET /v2/acts/{id}, and read access to every sub-resource including builds, input schemas, and source metadata. Build-read access is bundled into this permission — the separate Build checkbox is for triggering new builds (write-level), not for reading existing ones.

Which backend actors use it. Every backend specialist. The fleet-analytics orchestrator enumerates your actors as step one of every run. schema-validator, release-gate, and compliance-scanner read your actor definitions to check for drift, breaking changes, or policy violations. cost-watchdog matches actor IDs to memory and timeout settings for spend estimates.

With it, you get: a populated fleet view, Fleet Health Score computation, schema drift detection across builds, and Action Plan "Top fix" cards that reference specific actors.

Without it: every backend actor fails at step one with 403 Forbidden on /acts. The dashboard is empty.

Actors: Run

What it grants. POST /v2/acts/{id}/runs and POST /v2/acts/{id}/run-sync-get-dataset-items — the trigger-runs permission.

Which backend actors use it. Every Run button in the dashboard fires run-sync-get-dataset-items on one of the backend actors. You pay for these runs on your own account via Apify Pay-Per-Event pricing, which is why ApifyForge only triggers runs when you click Run — it does not run on a schedule or in the background.

With it, you get: real analytics on demand when you click any Run button.

Without it: cached data still displays, but every Run button returns 403. The FirstRunExperience on a fresh account never completes.

Actors: List runs

What it grants. GET /v2/acts/{id}/runs — run history with status, duration, memory consumption, cost per run, plus read access to each run's default dataset and key-value store.

Which backend actors use it. fleet-analytics for failure rate and cost aggregates, cost-watchdog for spend-per-actor tracking, ab-tester for variant comparison, quality-monitor for week-over-week degradation detection.

With it, you get: real failure rates, real cost numbers, regression signals, and Action Plan items computed from actual history.

Without it: the dashboard looks populated but every metric is zero. Action Plan is blank or generic.

Storages: Read

What it grants. GET /v2/datasets/{id}/items, GET /v2/key-value-stores/{id}/records/{key}, and equivalent endpoints for request queues — for every storage owned by your account.

Which backend actors use it. Effectively every backend actor, because run-sync-get-dataset-items returns the dataset in the same HTTP response as the run trigger. Without Storages: Read, that combined endpoint fails on the read half with 403 — the run still consumes credits, but the response never includes the data.

Important: see the Honest disclosure section above for the crucial nuance — this permission is wider than "datasets ApifyForge produced" and the guarantee is procedural.

Without it: runs burn credits but the dashboard shows nothing. Worst failure mode.

Storages: Write

What it grants. PUT /v2/key-value-stores/{id}/records/{key}, POST /v2/datasets/{id}/items, and the delete endpoints for storages you own.

Which backend actors use it. Every backend actor writes its OUTPUT to its default key-value store (standard Apify convention). fleet-analytics writes trend snapshots so next week's run can compute week-over-week deltas. The dashboard-native acknowledgement flow (when it ships) will also write per-item ack state here.

⚠️ Destructive-capability warning. Of the five scoped permissions, Storages: Write is the only one that is genuinely destructive if the token leaks. A stolen token could push malicious data into your datasets, overwrite or delete records in key-value stores, or corrupt run outputs. Read-only permissions cannot do that. Apify's permission schema does not let you narrow write access to "KV stores only" or "our actors' outputs only" — if you grant it, the token can write anywhere in your storages. Mitigations in the Production hardening section below.

Without it: actor runs fail at the save step. The actor starts, does its work, then crashes when it tries to save. No data persists. The entire backend fleet becomes inoperative.

Blast radius if the token leaks

The worst-case damage from a leaked scoped Apify API token is bounded. An attacker could:

Read all storages owned by your account, including dataset contents
Write to those storages — corrupt, overwrite, or delete records (the destructive risk from Storages: Write)
Trigger runs on your actors, burning through Apify credits on your bill

An attacker could NOT modify your actors, touch your billing, create new tokens, change your schedules, configure webhooks, or manipulate your account in any other way. The most important mitigation for the cost-drain risk is a budget alarm at console.apify.com/billing — that caps how much a compromised token can burn through regardless of application-level protection.

How ApifyForge stores and protects your token

Your token is encrypted with AES-256-GCM using a 256-bit key held in the server's TOKEN_ENCRYPTION_KEY environment variable. The encryption key lives only in the ApifyForge server environment — never in the database, never in logs, never in backups. A full database dump would yield only ciphertext with no way to decrypt it.

When an analytics run needs to talk to Apify, the server reads the ciphertext, decrypts it in memory, makes the API call, and discards the plaintext. The plaintext is never logged, never written to a file, and never sent to any third party.

Revocation paths — either works independently:

In ApifyForge: Settings → Apify API Token → Delete token. Clears the encrypted_token column from the database. ApifyForge can no longer run anything on your account.
In Apify: console.apify.com/settings/integrations, find apifyforge-dashboard, click Revoke. Invalidates the token everywhere, not just in ApifyForge. The definitive off switch — works even if ApifyForge is unreachable.

You can revoke access at any time instantly from Apify — this is a one-click hard stop. No multi-day waiting period, no support ticket, no negotiation. It takes effect immediately because it is enforced by Apify's own API.

For the full token storage architecture, see Do you store my API token?.

Production hardening

The scoped token model above is already dramatically safer than a full-access integration, and is fine for most users doing experimentation, side projects, or smaller Apify accounts. But if you are running ApifyForge against a business-critical Apify account where downtime, data corruption, or unplanned spend would cause real revenue loss, layer these additional controls on top of the base setup:

Rotate the token every 30 days instead of every 90. A shorter rotation cadence shrinks the window an exfiltrated token could be used in. Production accounts should treat token rotation as monthly hygiene.
Set a tight budget alarm in Apify at console.apify.com/billing. Set a monthly spending cap at roughly 150 percent of your known baseline. This caps cost-drain damage from a leaked token at a known ceiling regardless of any application-level protection. The single highest-leverage control you can add.
Monitor your Apify run history for activity you did not initiate. Unexpected runs, KV store writes, or dataset pushes are the earliest visible signal of a compromised token. A quick daily glance at console.apify.com/actors/runs catches most anomalies.
Consider the CLI flow instead of the browser token flow. The CLI (npx apifyforge run <tool>) keeps the token entirely on your own machine — there is no server-side copy to exfiltrate, so a compromise of ApifyForge's application server cannot leak your token. Both flows produce identical analytics in the dashboard.
Use a dedicated Apify account for ApifyForge where possible. The strongest isolation comes from running ApifyForge against an Apify account that contains ONLY the actors you want monitored — separate from your main production account.

None of these controls is strictly necessary. The base scoped token model is already safer than any full-access integration. But for high-stakes accounts, layering them on top moves the risk profile from "sensible default" to "hardened for production."

Should you connect your account?

You can safely connect ApifyForge with a scoped token if:

You want analytics across your Apify actor fleet without building a custom dashboard
You are comfortable granting read + write access to your Apify storages, with a dedicated token and budget alarm in place
You run a small-to-mid-size Apify account where the fleet analytics value justifies the trust trade-off
You understand the Honest disclosure above about Storages: Read being wider than "metadata only"

You should use the CLI flow instead (or reconsider entirely) if:

Your datasets contain highly sensitive or regulated data — PII under GDPR, PHI under HIPAA, PCI-DSS-scoped data, customer records
You cannot tolerate any destructive write-level risk on your key-value stores or datasets
Your threat model assumes ApifyForge's application server itself could be compromised
You run a mission-critical production Apify account with no budget alarm in place

The CLI flow (npx apifyforge run <tool>) keeps the token entirely on your own machine and produces identical analytics — no trust trade-off on the server side.

Scoped token vs full-access token

For reference, here is what the five-box scoped token grants compared to a full-access token:

Capability	Scoped token	Full-access token
List actors and read metadata	✅	✅
Read build history and schemas	✅	✅
Trigger actor runs	✅	✅
Read run history, cost, duration	✅	✅
Read/write your own storages	✅	✅
Modify actor source code	❌	❌ (blocked at Apify platform level)
Delete or rename actors	❌	✅
Trigger new actor builds	❌	✅
Abort, restart, or modify runs	❌	✅
Manage actor webhooks	❌	✅
Manage schedules	❌	✅
Change Apify billing	❌	❌ (never exposed to any token)
Create new API tokens	❌	❌ (never exposed to any token)
Read Apify Tasks	❌	✅
Blast radius if leaked	Low — storages + runs only	High — whole account

Frequently asked questions

Is ApifyForge safe to use?

Yes, when you follow the token creation guide — create a scoped token, set a budget alarm, rotate every 90 days, and monitor Apify run history for unexpected activity. ApifyForge restricts data access to exactly what its scoped Apify API token grants: metadata, run history, and your own storage contents. It never sees your actor source code, environment variables, billing, or proxy credentials. With a budget alarm in place, even the cost-drain risk from a leaked token is capped at a known ceiling. The destructive-capability warning around Storages: Write is the one thing that requires careful thought — if your storages contain highly sensitive data, use the CLI flow instead.

Can ApifyForge see my data?

ApifyForge can see your actor metadata, run history, and the contents of storages you own — but not your actor source code, environment variables, billing, or any data owned by other Apify users. Dataset contents specifically: the scoped token technically allows reading every dataset in your account, but ApifyForge's code only reads datasets produced by the backend analytics actors it ran on your behalf. Your other datasets (the ones your own scrapers produced) are never fetched, cached, or persisted anywhere in ApifyForge's systems. See the Honest disclosure section above for the procedural-vs-technical guarantee.

Does ApifyForge access my datasets?

Only the datasets produced by the backend actors ApifyForge runs on your behalf — not the datasets your own scrapers produce. The scoped token grants read access to all datasets in your account at the permission level, but ApifyForge's code specifically fetches only the datasets returned from run-sync-get-dataset-items calls it initiated. Your other datasets' row data is never loaded into memory, never cached, and never persisted on the ApifyForge server. This is a procedural guarantee enforced by ApifyForge's code, not a technical guarantee enforced by Apify's permission schema. If that distinction matters to you, use the CLI flow — it keeps the token entirely on your own machine.

What data does ApifyForge store in its database?

Computed analytics — Fleet Health Score, failure counts, cost aggregates, quality scores, trend deltas — not the raw data those analytics were computed from. The cache contains things like "Fleet Health Score = 64", "actor X failed 3 times this week", "estimated monthly cost = $180" — not the raw dataset rows. The cache is cleared automatically when you delete your token and can be forcibly cleared from Settings at any time. The token itself is separately encrypted with AES-256-GCM using a server-held key; see Do you store my API token? for the full storage architecture.

What happens if my Apify API token leaks?

An attacker could read your storages, write to your storages (destructive), and trigger runs on your actors — but nothing else. The scoped token's blast radius is bounded: read metadata, read and write storages, trigger runs. It cannot modify actor code, access billing, create new tokens, or touch anything outside your own storages and runs. Mitigations: set a budget alarm in Apify, monitor run history daily, and revoke the token immediately in Apify at the first sign of compromise.

Is ApifyForge GDPR-compliant if my datasets contain personal data?

Yes, ApifyForge can be used in GDPR-compliant setups — but for datasets containing regulated personal data, the recommended approach is the CLI flow to avoid server-side token storage. ApifyForge does not store your raw dataset contents and only caches computed analytics that are not themselves personal data. The scoped token does technically have read access to every dataset in your account, which means the token itself has the capability to read datasets containing personal data — but ApifyForge's code only reads datasets produced by its own backend actors, not your scrapers' outputs. For regulated data (PII under GDPR, PHI under HIPAA, PCI-DSS-scoped data, etc.), the cleanest architecture is the CLI flow (npx apifyforge run <tool>), which keeps the token entirely on your own machine and never hands it to any ApifyForge server. Both flows produce identical analytics in the dashboard, so choosing the CLI flow for regulated datasets is a no-compromise decision.

How do I create a scoped Apify API token for ApifyForge? — the step-by-step walkthrough
Do you store my API token? — how the token is encrypted, stored, and revoked
How do I connect my Apify account? — the browser token flow vs the CLI flow
How do I disconnect my account? — how to revoke access if you change your mind

Last updated: April 14, 2026