Skip to main content

​
Overview

The API tester is a built-in HTTP client embedded in every engagement. Rather than switching between Burp Suite, Postman, or curl for every request, you can stay in Pwnbook and have all your requests saved, organized, and tied to the engagement. Requests are stored per engagement, so your whole team can see what’s been tested, replay requests, and build on each other’s work.

​
Creating an API request

  1. Navigate to your engagement and select the API Requests tab.
  2. Click New Request.
  3. Configure the request:
    • Method: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS
    • URL: The full target URL, e.g., https://api.example.com/v1/users
    • Headers: Add any required headers (Authorization, Content-Type, etc.)
    • Body: Enter the request body for POST/PUT/PATCH requests. Supports raw text, JSON, and form data.
  4. Click Send to execute the request.
The response appears in the right panel, including status code, response headers, body, and timing information.

​
Saving requests

After configuring a request, save it for later use:
  1. Click Save in the request editor toolbar.
  2. Enter a name for the request (e.g., “Admin Login”, “Create User - Missing Auth”).
  3. Optionally organize it into a folder.
  4. Click Save.
Saved requests appear in the left sidebar and can be re-opened, edited, and re-executed at any time.

​
Execution history

Every request you send is automatically logged in the execution history. To review past executions:
  1. Open a saved request.
  2. Click the History tab.
  3. Browse past executions by timestamp.
  4. Click any entry to view the full request and response as it was sent and received.
Execution history is useful for tracking what you’ve tested and for reproducing specific responses when documenting findings.

​
Request templates

Request templates are reusable starting points for common testing patterns. Instead of building every request from scratch, start from a template and customize it.

​
Using a template

  1. Click New Request → From Template.
  2. Browse the available templates.
  3. Select a template and click Use Template.
  4. Modify the template values as needed and send.

​
Creating a template

After building a request you’d like to reuse:
  1. Open the saved request.
  2. Click Save as Template.
  3. Enter a template name and description.
  4. Choose whether to share it with your organization or keep it personal.
  5. Click Save.

​
Community and global scripts

Community scripts are pre-built request collections contributed by the security community. They target common vulnerability classes, authentication patterns, or application frameworks.

​
Browsing community scripts

  1. Click Community Scripts in the left sidebar.
  2. Browse by category (Authentication, Injection, Business Logic, etc.) or search by keyword.
  3. Click a script to preview what it does.
  4. Click Import to add it to your engagement.

​
Running a script

Imported scripts appear in your request list. Some scripts are parameterized — you’ll be prompted to enter values like the target URL, authentication tokens, or user-specific data before running.

​
Global scripts

Admins and owners can publish organization-level scripts that are available across all engagements. This is useful for standardizing testing procedures across your team.

​
Packet templates

Packet templates extend the API tester to lower-level protocol interactions. Where API requests work over HTTP, packet templates let you work with raw TCP/UDP payloads for testing non-HTTP services.
Packet templates require the recon worker to be running and accessible, as packet-level operations are handled by the worker service.
To use a packet template:
  1. Navigate to API Requests → Packet Templates.
  2. Click New Packet Template.
  3. Select the protocol (TCP, UDP).
  4. Define the target host and port.
  5. Enter the raw payload (supports hex encoding for binary data).
  6. Click Send Packet.

​
Tips for effective API testing

Set common values like base URLs, authentication tokens, or user IDs as variables in the request editor. Reference them with {{variable_name}} syntax to avoid repetition across requests.
Group related requests into folders within the engagement (e.g., “Authentication”, “Admin Endpoints”, “User API”). This keeps large test suites manageable.
When you find an interesting response — an error message, an unexpected data leak, a bypass — leave a comment on the saved request so the team knows what was discovered.