Schellman describes an API penetration test as a distinct assessment that interacts directly with an API, rather than assuming a general application test will cover its unique weaknesses. Its published minimum is $14,500. RSI Security lists $7,950.00–$28,250.00 under a selector labeled “Per API,” but its options are labeled by test count, so the page does not establish a uniform per-API price across that range. Stingrai publishes US$3,000 for an autonomous assessment and US$6,800 for a hybrid assessment of one web application and associated APIs. Those figures describe different offers. A buyer cannot use them as a market average or compare them as though each covers the same application, identity model, and evidence package.
Quick answer. An API penetration test costs what the agreed API scope and delivery model require; the public pages above offer individual vendor anchors, not a universal price band. The first buying decision is whether the statement of work covers the API alone or the browser application and its associated APIs together. Then normalize every quote against the same API inventory, roles, tenants, authentication flows, sensitive transactions, retest terms, and report evidence. Stingrai's published fixed packages cover one web application and associated APIs; a standalone API or a larger program needs a scoped custom quote.
This guide is for security leaders, application owners, and procurement teams who need a defensible purchase decision, especially where an enterprise customer will review the result. It deliberately does not invent a typical price for an endpoint, a tenant, or a tester day. The practical output is a scope sheet you can send to vendors, followed by a way to compare their responses without silently accepting different tests.
What the published prices actually describe
The three public examples answer different questions. Read the description beside the price before using any number in a budget.
Public offer | What the vendor prints | What to clarify before comparison |
|---|---|---|
“No less than $14,500” for an API penetration test. Schellman also says API-focused assessments take 1–3 weeks depending on endpoints and supported methods. | The API inventory, methods, authentication materials, final effort, report, and retest terms for your scope. | |
$7,950.00–$28,250.00 across choices labeled 1st Test, 2nd Test, and 5th+ Tests under a “Per API” selector. The page says the offer includes five hours with a project manager. | What each test-count choice covers, how many APIs and operations are included, which identities are tested, and how retesting is handled. | |
US$3,000 Autonomous Pentest or US$6,800 Hybrid Pentest, each for one web application and associated APIs. | Whether your estate fits one application and its associated APIs, and whether you need autonomous or human testing alongside Snipe. Standalone API and broader estates require a custom scope. |
The Schellman and RSI pages use a dollar sign without spelling out a currency in the cited price text, so this table reproduces their notation. Stingrai's page explicitly says its prices are in USD. These are published vendor offers, not a survey. The smaller number is not evidence of a weaker test, and the larger one is not evidence of a broader one. The scope and deliverables decide whether the figures can even sit on the same comparison sheet.
Published prices are still useful. They show why a request for “an API pentest” cannot be approved on a bare total. Schellman says it needs documentation describing authentication methods, endpoints, methods and parameters, plus credentials or access keys for authenticated requests. RSI labels its selector “Per API” while offering choices by test count and listing report contents. Stingrai states the boundary of its fixed package. Each vendor is telling the buyer that the noun API alone is too imprecise for a final scope.
None of these three cited product pages publishes a tester-day rate for the quoted offer (Schellman, RSI Security, Stingrai). Schellman's 1–3 weeks is an elapsed assessment duration, not a count of billed tester days. Dividing a public package price by that window would manufacture a rate the vendor did not publish. Where a bidder does quote by day, ask which days cover discovery, manual testing, reporting, and retesting, and whether those activities have different rates.
The buying fork: API only or web application plus APIs?
An API-only test is appropriate when the product surface to assess is an API, such as a partner integration, service interface, or headless backend. The statement of work should say which hosts, versions, protocols, methods, identities, and data flows are in scope. A tester may use a request collection and direct API calls rather than navigate a browser interface. Schellman explicitly describes direct interaction with the API and its intended use in its API service description.
A combined web and API test is appropriate when the buyer needs evidence for the user-facing workflow and the service calls beneath it. The browser application can introduce its own session, client-side, and workflow questions. The API can expose the same business object through other clients, roles, or versions. A combined scope should state whether the tester will follow a transaction through both surfaces and compare the security decision at each boundary. A proposal that mentions both words in its title without listing the actual surfaces leaves this unresolved.
Figure 1: A buyer's choice of API-only or combined browser and API scope, with the access and evidence questions that should be written into either proposal. Sources: Schellman, API Penetration Testing and OWASP API Security Top 10.
Neither choice is automatically more thorough. An API-only engagement can be deep and manual across many identities. A combined engagement can be shallow if its API component is only traffic captured while clicking through a single browser role. Ask what will be tested independently of the browser: partner endpoints, mobile backends, background jobs, older versions, administrative operations, and routes unavailable from the chosen UI account. OWASP's API inventory guidance calls out hosts, environments, versions, access audiences, and integrated services because an incomplete inventory creates an incomplete test boundary.
For procurement, the decision can be written plainly:
Business need | Scope to ask for | Question that exposes a gap |
|---|---|---|
A partner or machine client uses the API without the web application | API-only, including the partner identity and its permitted operations | Can the tester reach and exercise the partner routes without relying on the browser workflow? |
Customers use a browser while partners and mobile clients use the same backend | Combined web and API, or linked scopes with a shared access model | Will the report compare the authorization decision across each in-scope client route? |
Several products share an API gateway | Explicit service boundaries, not one vague “gateway” asset | Which downstream services, versions, and tenant data stores are included? |
An enterprise customer asks for evidence on an exposed integration | API-only may be sufficient if the requested integration is the full review boundary | Will the final report name the tested operation set and excluded adjacent surfaces? |
The last row is a procurement judgement, not a substitute for the customer's actual contract or questionnaire. A buyer should map the requested evidence to the application architecture and then ask the vendor to state the boundary in writing.
Why endpoint count is a weak price shortcut
An endpoint count helps estimate discovery and request coverage, but it does not measure the whole test. One URL may support several HTTP methods, parameter combinations, or privilege paths. A versioned API may expose the same operation in more than one deployment. A GraphQL endpoint can present many object and field operations under a single URL. OWASP API9 makes the inventory problem explicit: hosts, versions, environments, and third-party data flows need visibility. Schellman ties its published 1–3 week duration to endpoint and method count, rather than naming endpoints alone (source).
Ask the vendor how it counts a unit of work. Does “endpoint” mean a unique route, a route and method pair, a GraphQL operation, or an item in an OpenAPI specification? Are duplicate methods across versions separately tested? Is a webhook receiver part of the API under review? There is no universal counting convention in the public offers cited above. A proposal should define its own convention so procurement can reconcile the asset list with the report.
The most expensive difference may be state, not route count. A read operation for an object can behave differently for its owner, a same-role user, a user in another tenant, and an administrator. A write operation can have a different property-level rule. OWASP's API Top 10 treats object, property, and function authorization as distinct risks. A proposal that counts routes but never states identities may estimate the easy part and omit the access-control work that matters to the business.
The buyer can remove ambiguity without creating an exhaustive request spreadsheet. Provide an OpenAPI document or request collection, then add a short list of the identities, business objects, and state changes that matter. Ask the vendor to identify where it will sample equivalent routes and where it will test each route individually. That is more honest than promising full manual coverage of every parameter without knowing how the system behaves.
The cost drivers that deserve separate lines in the quote
API inventory, versions, and environments
Begin with the complete API host list, including public, partner, administrative, and internal interfaces that the engagement is authorized to reach. Record production, staging, and test environments separately. List active versions and any older version that remains callable. OWASP API9 identifies missing or outdated host and version inventories as a security risk. In a quote, an unknown inventory is also a scheduling risk: discovery work will either consume assessment time or be left outside the agreement.
Ask whether discovery of undocumented but reachable endpoints is included, and what happens when the tester finds a service not on the initial asset list. A useful statement of work has a change-control rule: who can add a discovered host, who authorizes testing, and whether more effort changes the price. Avoid treating the vendor's asset discovery as proof that every discovered service received the same depth of testing.
Operations, parameters, and protocol features
Count the operations that change risk, not simply the names of routes. Read, write, delete, export, bulk update, and administrative actions may share a resource but require different permissions. REST methods, GraphQL mutations and queries, async jobs, and event callbacks can each reach the same object through a different path. OWASP API3 specifically distinguishes a caller reading a restricted property from changing one. OWASP API5 is about whether the caller can invoke a function at all.
The quote should state whether the tester reviews API documentation, captures real workflow traffic, tests unknown operations, or combines these. It should also state whether source-assisted review is part of the work. Each approach changes the evidence available and the time spent on setup. A buyer cannot infer those choices from “OWASP API Top 10 coverage.”
Roles, delegated identities, and tenants
Access-control testing needs identities with known entitlements. For a multi-tenant product, provide safe test tenants with distinguishable records and paired accounts. For a role-based product, include the ordinary, privileged, delegated, and service identities that drive sensitive operations. Then ask the vendor to compare expected and observed decisions across those boundaries. OWASP API1 concerns access to a particular object, while API5 concerns access to a function. A single privileged login cannot demonstrate separation between tenants or peers.
This is where “up to three roles” and “all roles” require careful interpretation. Count the specific identities and boundaries, not just job titles. Two accounts with the same role in different tenants can reveal a different class of problem from two roles in one tenant. A service principal with broad access may need its own test policy. The vendor should say which cross-role and cross-tenant comparisons it will perform, rather than assume that authenticated access alone covers authorization.
Authentication and token lifecycles
Tell bidders how human users, service clients, and partners authenticate. Note session creation, refresh and revocation, SSO, OAuth grants, API keys, mutual TLS, or signed requests where relevant. OWASP API2 treats broken authentication as a separate API risk, and Schellman asks for authentication documentation and usable credentials to perform an authenticated test (source).
The quote should say who supplies identities, whether the test includes identity-provider configuration or only the API's handling of issued credentials, and how expired or revoked credentials will be assessed. Those are different boundaries. An API assessment that starts with a valid bearer token can still be valuable, but the buyer should not describe it later as a full review of the identity provider.
Sensitive business flows and third-party effects
The price can change when a tester needs to understand a business process instead of checking isolated requests. Approvals, payouts, invitations, bulk exports, reservations, and account recovery involve state and sequencing. OWASP API6 describes risk from excessive use of sensitive flows even when the individual request may be allowed. The business owner needs to identify the harm and the safe test limit; a vendor cannot derive those from an endpoint list alone.
For systems connected to external services, specify which callbacks, webhooks, payment sandboxes, or notifications may run during testing. Supply seeded records and a clear stop condition. The vendor should separate a safe simulation from a real downstream effect in its plan. That preparation protects the engagement window and makes the finding evidence interpretable without exposing customer data.
Reporting, remediation, and retest evidence
An enterprise buyer often purchases the report as much as the test. Specify the report audience and content: executive summary, affected operation and identity, expected versus observed access, business impact, remediation guidance, tested environment and version, and exclusions. RSI's public offer, for example, describes a report with affected endpoints, risk ratings, proof, and remediation guidance (source). Ask for a redacted sample so procurement can judge the actual output.
Retesting needs a line of its own. Ask whether it is included, what finding classes qualify, how long the window lasts, whether a changed route is considered the same finding, and what closeout artifact the vendor issues. Stingrai's pricing page lists automated retests with its Autonomous package, and its service overview says retesting is included in its engagements. A generic promise of “validation” should be translated into a concrete output: a new observation tied to the repaired version and an updated status in the report or portal.
Figure 2: The procurement dimensions that should line up across API proposals, including a prompt to mark exclusions so a lower total cannot hide a smaller scope. Sources: OWASP API Security Top 10, Schellman API Penetration Testing, and RSI Security API Penetration Test.
A scope sheet to send to every bidder
Send the same written scope to each firm. Fill in only what is known and ask bidders to state assumptions rather than inventing your environment. The worksheet below is a procurement template, not a claim that every API needs every row.
Scope field | Buyer supplies | Vendor must state in the quote |
|---|---|---|
Business boundary | Product, customer journey, partner integration, and the reason for the test | Whether the offer is API-only or combined web and API testing |
Inventory | Hosts, environments, versions, OpenAPI or request collection, known undocumented routes | Included hosts and versions; discovery method; treatment of newly found assets |
Operations | Sensitive reads, writes, exports, bulk actions, callbacks, GraphQL or async jobs | Coverage method and any sampled or excluded operation families |
Access model | Roles, service clients, partner accounts, delegated access, test tenants, expected permissions | Authenticated identities used and role or tenant comparisons planned |
Authentication | SSO, tokens, keys, mutual TLS, refresh and revocation behavior | Whether identity-provider configuration, token handling, or only authenticated API use is in scope |
Business flows | Approvals, payouts, invitations, account recovery, limits, downstream effects | Which sequences will be tested and what safety controls apply |
Test access | Safe accounts, seeded records, staging parity, production guardrails, contacts | Prerequisites, start conditions, authorized window, and change-control rule |
Evidence | Report audience, redaction needs, customer questionnaire or audit deadline | Report contents, coverage statement, proof standard, and delivery date |
Remediation | Expected fix window and release cadence | Retest inclusion, eligibility, window, and final closeout artifact |
The scope sheet is deliberately more specific than “test our API.” It makes the quote falsifiable: after the test, the buyer can compare the final coverage statement with the agreed inventory and access model. The API authorization test matrix provides a deeper companion for object, property, function, and tenant evidence once the commercial boundary is set.
Where the system contains secrets or customer data, share sanitized documentation during procurement. Real credentials should move through an agreed secure access process after the engagement is authorized. The bidder needs to understand the type of identity and workflow, not receive production keys in an RFP attachment.
How to normalize API quotes without false precision
Place each proposal beside the scope sheet and mark every row included, excluded, optional, or assumed. Ask the vendor to replace “assumed” with a concrete boundary before signature. A total price is comparable only when the business boundary, identities, operations, evidence, and retest terms are comparable. This is especially important when one store labels its selection “Per API” but its options vary by test count, while another offer covers a web application and associated APIs.
Then read the proposed testing method. Does the vendor perform authenticated requests against the documented operations? Does it test object and tenant boundaries with paired identities? Does it examine both read and write properties, administrative functions, and sensitive flows? Does it identify versions or hosts that it will discover but not test deeply? Map the answer back to OWASP's distinct API risk categories, but do not treat a category checklist as proof that the necessary identities and business rules were available.
Finally, compare the evidence contract. One proposal may include a report and retest, while another lists testing alone and prices follow-up separately. One may give a coverage table suitable for an enterprise customer's review; another may provide findings without describing passed boundaries or exclusions. These are commercially material differences even where the test effort looks similar. Stingrai's guide to evaluating a penetration test report helps a buyer inspect the deliverable itself.
Do not calculate a “price per endpoint” from the public offers above. The Schellman page does not publish its endpoint count, RSI's store label does not define the internals of each API selection, and Stingrai's fixed package spans a web application and associated APIs. Dividing their totals by a guessed endpoint count would create a figure no vendor actually quotes. The right comparison is the total for a shared, written scope, with exclusions and retest conditions visible.
Quote language that should trigger a follow-up
“All APIs included.” Ask for named hosts, versions, and environments. An API gateway can route to multiple services; a mobile backend or partner version may not be visible from the main browser journey. OWASP API9 is the reason the inventory needs to be explicit.
“Authenticated testing included.” Ask which roles and tenants are available and which comparisons will be made. One token proves that a tester logged in, but it does not prove that object, property, or function authorization was challenged across identities. OWASP API1, API3, and API5 are separate categories for a reason.
“OWASP Top 10 covered.” Ask how the vendor will translate the categories into your product's operations and report evidence. A generic list cannot show whether a payout approval, bulk export, or partner callback was exercised safely.
“Retest available.” Ask whether it is in the quoted fee and what final evidence will be provided. A retest promise without a window or deliverable is hard to budget and hard to use in a customer review.
“One API.” Ask how the vendor defines it: a domain, gateway, microservice, product boundary, or collection. RSI's store uses a “Per API” selector with test-count options (source); a buyer should get the commercial unit and quantity behind the selected option written into the order form.
These phrases are questions, not automatic disqualifiers. The vendor may have a sound method behind a short marketing sentence. The procurement task is to turn that method into an agreed scope before the price is accepted.
Where Stingrai fits
Stingrai is a CREST-accredited penetration testing service provider headquartered in Toronto. Its human-led web and API testing can be scoped around authenticated roles, business logic, and authorization boundaries, with findings posted as they are confirmed and retesting of remediated findings included (delivery overview). Human-led and hybrid reporting provides evidence that can support a customer's security review or a compliance program. Stingrai offers one-time assessments and continuous programs through its PTaaS platform.
For a bounded web application, Stingrai's pricing page publishes an Autonomous Pentest at US$3,000 per assessment and a Hybrid Pentest at US$6,800 per assessment, each covering one web application and associated APIs. Autonomous is Snipe alone; Hybrid has Snipe and penetration testers testing together throughout. The published Autonomous scope specifies up to 200 API endpoints or dynamic pages and up to 3 user roles for authenticated testing (pricing). Those limits are package terms, not a formula for pricing an unrelated API estate.
A standalone API, several products behind a gateway, additional tenant models, or a wider enterprise estate should be described in a custom quote. Stingrai can propose a human-led API engagement when the buyer needs named penetration testers and specific cross-role evidence. The useful first message is the scope sheet above: architecture, hosts, identities, tenant test data, critical workflows, and the evidence your customer or internal reviewer will actually read.
Frequently Asked Questions
How much does an API penetration test cost in 2026?
There is no defensible single market price for an API penetration test. Schellman publicly says its API test costs no less than $14,500, while RSI Security displays $7,950.00–$28,250.00 across test-count choices under a “Per API” selector; their published pages do not describe an identical scope (Schellman, RSI Security). Stingrai's separate published packages are US$3,000 autonomous and US$6,800 hybrid per assessment of one web application and associated APIs (pricing). Use those figures as vendor-specific anchors, then request a price against your written inventory, identities, workflows, report, and retest requirements.
Is an API-only pentest cheaper than a web and API pentest?
Not necessarily. An API-only assessment may require extensive authenticated testing across partner identities, tenant boundaries, versions, and business flows. A combined web and API assessment may cover a narrower application boundary. Compare the operation and identity coverage in the statement of work rather than infer effort from the labels. Schellman treats API testing as a distinct service and asks for detailed API documentation and credentials to scope it (source).
What should an API pentest quote count as an endpoint?
The quote should define its own counting convention. Ask whether an endpoint is a route, route and method pair, GraphQL operation, or item in a request collection, and how versions, webhooks, and administrative functions are counted. OWASP calls for inventory of API hosts, versions, environments, and integrations (API9); endpoint count alone does not describe those boundaries.
How many test accounts should we provide?
Provide enough approved accounts to represent each role, peer, tenant, delegate, and service identity that the agreed access model requires. The count is product-specific. A single administrator account cannot demonstrate whether a peer user or another tenant is blocked from a record. Define the expected decision for each pairing, and ask the vendor which comparisons it will perform against OWASP's object, property, and function authorization categories.
Should retesting be included in the API pentest price?
It should be specified before purchase. Ask whether the quoted fee includes retesting, what findings qualify, the time window, and the closeout artifact. A useful retest result identifies the repaired version and updated finding status. Stingrai's pricing page lists automated retests with its Autonomous package, and its service overview says retesting is included in its engagements.
Does a web application pentest automatically cover every associated API?
No. The answer depends on the written scope. Browser traffic may reveal only the routes exercised by the supplied account, while a partner client, mobile app, older version, or administrative service may reach others. Ask for a named host and operation inventory and a statement of what was tested independently of the browser. OWASP API9 explains why host and version visibility matters.
Related reading
References
Schellman, Application Program Interface (API) Penetration Testing. Public service description, pricing minimum, duration, and scoping inputs. Read 23 October 2026.
RSI Security, API Penetration Test. Public store range, unit label, and deliverables. Read 23 October 2026.
OWASP, API Security Top 10, 2023 edition. Risk categories and linked definitions. Read 23 October 2026.
Stingrai, Plans and Pricing. Public package prices and scope boundary. Read 23 October 2026.
Stingrai, PTaaS Platform. Portal delivery. Read 23 October 2026.
Stingrai, Service Overview. Retesting and real-time findings. Read 23 October 2026.
CREST Marketplace, Stingrai Inc.. Penetration Testing accreditation. Read 23 October 2026.
Talk to Stingrai
Send your API inventory, identity map, critical flows, and required report evidence through Get a Quote, or book a free discovery call to decide whether an API-only or combined web and API assessment fits the boundary you need reviewed.
