4. August 2026
Snyk Platform Subscription
Understanding the Snyk Platform Subscription
The Snyk Platform Subscription is a consumption-based license for Snyk platform capabilities. Use of these capabilities draws down Credits from a pre-purchased balance, based on the Rate Card and the units of measure described below. Once the pre-purchased Credit balance is exhausted, any further use will be invoiced as on-demand consumption.
Credits Rate Card
Capability | Credit Consumption Rate | Unit of Measure |
Secrets | 0.66 credits | per Active Contributor per Day |
API and Web | 3.0 credits | per Provisioned Target per Day |
AI Pentesting | 4,000 credits | per Assessment |
How We Calculate "per Active Contributor per Day"
Credit consumption for platform capabilities measured “per Active Contributor per Day” is determined by the daily count of Active Contributors across all repositories monitored by that capability. Consumption begins on the day monitoring begins and ends the day after the repository is removed from monitoring. A repository monitored for part of a day consumes a full day's Credits.
An Active Contributor is any unique contributor acting for or on your behalf who has made a commit to a private, Snyk-monitored repository during a rolling 90-day period. Active Contributors may be human or non-human. They include, for example, your employees, independent contractors, agents, third-party bots, automated systems, and service accounts. Snyk-native automated bots, such as <snyk-bot@snyk.io>, are excluded from this count.
A repository is monitored by a capability when it is imported into an organization and at least one of its projects is active for that capability. When a project is created for a capability, its status is set to active and remains active until it is deactivated. A repository counts as monitored even if it is not actively scanned on a given day.
To count Active Contributors for a given capability, Snyk identifies each contributor by username across all repositories monitored by that capability. Each unique username counts as one Active Contributor, no matter how many monitored repositories it appears in.
Snyk derives a username from a contributor's email address by lowercasing it, trimming extra spaces, dropping any subaddress (including the plus sign as well as any characters between the parsed username and domain), and removing the domain. The deduplication logic also recognizes common variations of the same identity — such as standard email aliases and the private no-reply addresses used by GitHub and GitLab — to resolve them to a single username. The examples below show how different email formats reduce to a username.
Snyk reserves the right to review account activity and contributor identity data where it reasonably believes username manipulation or other identity patterns are being used to avoid accurate Active Contributor measurement.
Two important callouts:
Personal email addresses: Snyk cannot reliably link a personal email address to a corporate one, so a username derived from a personal email address is counted as an Active Contributor.
IP address domains: An email address whose domain is an IP address is not reduced to a username; the full email address counts as one Active Contributor.
Scenario | Example Email Address | Active Contributor Username |
|---|---|---|
Standard domain email address | john.doe@snyk.io | john.doe |
GitHub private email address | 12345678+jane.doe@users.noreply.github.com | 12345678 |
GitLab private email address | 12345678+john.doe@users.noreply.gitlab.com | 12345678 |
Email alias (plus addressing) | jane.doe+qatest@gmail.com | jane.doe |
IP address domain | root@192.0.2.5 | root@192.0.2.5 |
User with Two Emails | mike.smith@snyk.io | mike.smith |
Illustrative Example:

How We Calculate "per Provisioned Target per Day"
Credit consumption for API and Web is based on the number of provisioned targets in your account each day. Consumption begins on the day a target is added and ends the day after it is removed. Any target provisioned for part of a day will consume a full day’s credits.
Each unique base URL defined in the platform is a provisioned target. Admins can view and manage provisioned targets in the Targets section of the API and Web platform.

When a target is deleted, its records are discarded and cannot be recovered.
Provisioned targets include access to various scan types:
Type of Scan | Definition |
Standard Scan | A comprehensive security test that attempts to cover the target application’s entire attack surface. A standard scan maps accessible pages available through the target URL. |
Reduced Scope Scan | A targeted security test that focuses on a defined subset of the application's attack surface. A reduced scope scan is limited to certain URLs, paths, or areas defined by the scan configuration. |
Incremental Scan | A partial scan that scans only new or updated URLs. Incremental scans require a completed standard scan as the baseline. |
Retest | A microscan that retests a vulnerability to confirm that a fix was successfully applied. Retests scan a specific endpoint for a specific vulnerability, enabling you to quickly check if fixes were effective. |
How We Calculate "per Assessment"
Credit consumption for AI Pentesting is based on the number of completed Assessments. An Assessment means a complete run of Snyk's AI pentesting agents against a single Application, including related microservices called by that Application and any post-remediation retesting triggered as part of the Assessment.
An Application is the evaluated target of an Assessment. It is defined by a primary web URL, additional in-scope URLs, an allowed list, a reject list, and user credentials. Microservices are additional backend services or APIs that the Application calls and that are exercised during testing, as identified through the call graph observed during the run. All such microservices are covered under the single Assessment price, with no separate charge per microservice.
Post-remediation retesting is a follow-on workflow in which a vulnerability identified in an Assessment is fixed by the user, who may then prompt the agent to retest that same vulnerability to confirm its remediation. Upon retest, that same vulnerability is either confirmed as remediated, or it persists, in which case the retesting workflow can be repeated. Retesting is specific to vulnerabilities of an existing Assessment, is included as part of the original billing event in the ‘per Assessment’ rate and is not billed as a new event.
A complete Assessment lifecycle includes user initiation, target validation, vulnerability testing, risk analysis, and report production. An Assessment is complete only if it is not cancelled by Snyk or the user and does not result in a Scan Failure. Only completed Assessments count as billable usage; failed scans are excluded from that count.
A Scan Failure occurs when an attempted Assessment does not complete. Expected cases of failure include missing credentials, an unreachable target, and WAF blocking. Scan Failures are not charged.
Each Assessment tests a single Application and its secondary URLs. For especially complex targets with unique testing depth, a completed report may flag attack paths that merit deeper, dedicated testing; pursuing these is a separate Assessment that the customer chooses to run. During the testing stage, Snyk applies a token reasoning limit equivalent to $2,000 USD. If an Assessment approaches this limit, the agent identifies areas that require additional analysis, documents those areas in the report, and recommends a follow-up Assessment. The original Assessment still completes with a full Assessment report. The customer may choose to pursue the flagged areas as a separate billable Assessment.
Test Limits
Snyk products may be subject to test limits, as stated in an applicable Order and further detailed on this page.
Credit Usage Policy
Snyk Platform Credits (“Credits”) are a part of the issued subscription allocation and limited license grant to Snyk products and services. When Customer uses Credits, Snyk deducts the number of Credits required for the applicable services from Customer's Credit balance. Credits must be used within the term of the applicable Order, after which any unused Credits will expire and cannot be redeemed, refunded, or credited. Credits are not redeemable for cash and are non-transferable. Upon Customer's exhaustion of its prepaid Credits, Snyk may invoice Customer for any Credits consumed in excess of Customer’s prepaid Credit allocation at the applicable Credit consumption rates set out in the Rate Card and Customer’s per-Credit price set out in the applicable Order.