Common questions

Quick answers to help you understand where FroggerAPI fits in a Postman → OpenAPI → Tenable WAS workflow. The goal is clarity and predictable scanning — without changing how you run Tenable.

How does FroggerAPI relate to Tenable WAS?

FroggerAPI sits before Tenable WAS. It prepares and enforces OpenAPI specifications so the spec you upload into Tenable is accurate, hardened, and scan-ready.

Does FroggerAPI run Tenable WAS scans?

FroggerAPI focuses on preparing and enforcing OpenAPI specifications before scanning. Scans themselves are run in Tenable WAS using your existing workflow.

Does FroggerAPI replace Tenable WAS?

FroggerAPI complements Tenable WAS by ensuring the OpenAPI specifications you upload are consistent and scan-ready. Tenable remains your scanning engine.

Do developers need access to Tenable?

Developers submit Postman collections or OpenAPI files to FroggerAPI. Security teams retain full control over when and how approved specs are used in Tenable WAS.

Is CI/CD required?

CI integration is optional. Many teams use FroggerAPI as a pre-scan quality gate without integrating it into CI.

What problems does FroggerAPI solve?

FroggerAPI addresses specification-driven scan failures — for example: incomplete or inconsistent OpenAPI files, low-coverage scans caused by spec drift, and noisy findings caused by malformed definitions. It helps teams fix the spec before running scans.

Where does FroggerAPI fit in the workflow?

Before scanning:

Postman / OpenAPI
→ FroggerAPI (convert, harden, enforce)
→ Tenable WAS scan

Does FroggerAPI store or proxy API traffic?

FroggerAPI operates exclusively on API definitions, not live traffic.

Does FroggerAPI manage scan credentials?

Credential management remains with your existing systems and Tenable WAS configuration. FroggerAPI’s job is to ensure the specification being scanned is correct and enforceable.