How to Test an API Without Documentation (And Without Postman)

Testing an API without documentation means using curl, browser DevTools, or HTTPie to discover endpoints, infer schemas, and validate behaviour.

You've inherited a legacy API. No docs. No spec file. The engineer who built it left two years ago. You need to understand what it does, validate that it works, and eventually publish it so other teams can use it.

Or: you're integrating with a third-party service that has an API but the documentation is either missing, three versions out of date, or the classic "ask our sales team." Same problem.

And maybe you don't want Postman. You're on a locked-down machine, you don't want to create an account, you're working in a CI pipeline, or you just prefer tools that don't force you into a cloud workspace to make a GET request.

This guide is the practical, ICP-level playbook: how to discover what an undocumented API actually does, how to test it without Postman, and how to convert that reverse-engineering effort into something reusable.

TLDR
‍
1. Testing an API without documentation means discovering endpoints through traffic inspection, inferring request/response schemas from controlled calls, and validating behaviour incrementally
‍
2. You do not need Postman. cURL, browser DevTools, HTTPie, and Hoppscotch each handle the core workflow without an account, a GUI install, or cloud sync
‍
3. The five-phase approach: discover the surface, validate auth, probe schemas, isolate functional scenarios, then convert findings to a spec
‍
4. The biggest mistake is testing directly in production before you understand rate limits, side effects, or auth scope
‍
5. The end goal is not just passing tests. It's converting reverse-engineered behaviour into an OpenAPI spec, a sandbox, and a portal entry that stops the next engineer from doing this again

Why APIs Exist Without Documentation

Before the workflow, it's worth naming why this situation exists. Platform engineers inherit undocumented APIs in one of four ways, and which one applies changes how aggressive your testing approach should be.

• Legacy system APIs were built before API-first thinking was a norm. They work. Nobody documented them. The original team moved on. The API is load-bearing and nobody wants to touch it. This is the most common scenario in banking, insurance, and telco.
• Shadow APIs were built by a team to solve a specific problem, deployed to production, and never formally catalogued. They're discoverable through gateway logs but have no entry in any API catalog or documentation portal.
• Third-party underdocumented APIs have a developer portal that exists but hasn't been updated since the last major version. The authentication flow described doesn't match what the API actually does now. The endpoint list is incomplete.
• Inherited integration APIs come with an acquisition or a migration. Another company's internal API is now your problem. Their internal docs are either inaccessible or written in a way that assumes deep product knowledge you don't have.

In multi-gateway environments, shadow APIs and legacy APIs are the norm, not the exception. Most large enterprises have between 20% and 40% of their active API traffic routed through endpoints with no formal documentation. DigitalAPI's API discovery layer surfaces these across Kong, Apigee, AWS, and MuleSoft simultaneously, giving platform teams visibility into what's actually running before anyone has to do manual traffic analysis.

The Tools: Testing an API Without Postman

These are the tools that cover the full workflow without requiring Postman. Each has a specific use case.

cURL

The universal baseline. Pre-installed on Linux and macOS. Available on Windows via Git Bash or WSL. No account. No GUI. Scriptable. Every example in this guide uses cURL commands because they run anywhere.

Basic GET:

curl -i https://api.example.com/v1/users

The -i flag includes response headers, which is essential when you're trying to understand auth requirements, rate limiting signals, and content types from an unknown API.

POST with JSON body:

curl -X POST https://api.example.com/v1/orders \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -d '{"product_id":"123","quantity":1}'

cURL with verbose output (shows the full request/response cycle including TLS handshake):

curl -X POST https://api.example.com/v1/orders \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -d '{"product_id":"123","quantity":1}'

Use -v during discovery when you need to understand exactly what headers the server is sending back. Rate limit headers, auth challenges, and redirect chains are all visible here.

Browser DevTools Network Tab

Zero install, zero account. Every browser has it. Open DevTools (F12), go to the Network tab, trigger the action in the application that calls the API, and inspect the captured request and response.

This is the fastest way to discover undocumented API calls in a web application. If the API powers a frontend you can access, the Network tab gives you the full request: method, URL, headers, request body, response body, and status code. Copy as cURL from the right-click menu to replay it outside the browser instantly.

Particularly useful for third-party underdocumented APIs: browse the product, trigger actions, capture the underlying API calls that aren't in the documentation.

HTTPie

cURL with readable syntax and pretty-printed JSON responses by default. Easier to type, easier to read in a terminal. Pre-installed on many development machines, or pip install httpie.

http GET https://api.example.com/v1/users Authorization:"Bearer TOKEN"

Response comes back syntax-highlighted and formatted. Ideal for interactive exploration when you're making lots of calls and want to read responses without piping through jq.

Hoppscotch

Browser-based API client. No install required. Open hoppscotch.io in any browser and start making requests immediately. Supports REST, GraphQL, WebSocket, and SSE. Self-hostable via Docker if you need to keep API traffic off public infrastructure.

Useful when you're on a locked-down machine where installing software requires an IT ticket, or when you want to share a request with a colleague without exporting a Postman collection file.

Bruno

Local-first, open-source. Collections stored as plain text files in a folder alongside your code. No cloud sync. No account. Collections version-control naturally in Git.

The correct choice when you're building a persistent test library for an undocumented API and want it to live in the same repository as the integration code. Once you've reverse-engineered the endpoints, Bruno collections become your team's reference, not a personal Postman workspace that disappears when you leave.

(scroll to view full table)

Which tool for which scenario?
‍Discovering an API through gateway logs: cURL. Capturing calls from a web application: Browser DevTools. Interactive exploration with readable output: HTTPie. Testing on a machine where you can't install anything: Hoppscotch. Building a persistent test suite alongside code: Bruno.

The Five-Phase Workflow: How to Test an Undocumented API

Follow these phases in order. Skipping straight to functional testing without completing discovery and auth validation is how you end up triggering real transactions in a production system you don't understand yet.

Phase 1: Discover the API Surface

Before writing a single test case, you need to know what endpoints exist.

Check for a hidden spec file first. Many APIs have an OpenAPI spec that was never linked in any documentation. Try these paths before doing any manual discovery:

curl -i https://api.example.com/openapi.json
curl -i https://api.example.com/swagger.json
curl -i https://api.example.com/api-docs
curl -i https://api.example.com/v1/openapi.yaml
curl -i https://api.example.com/.well-known/openapi

If any of these return a 200 with a JSON or YAML body, you have a machine-readable spec. Feed it into Swagger UI or DigitalAPI's API documentation generator and skip phases 1 through 3 entirely.

Inspect gateway logs if you have access: API gateway access logs show every routed path, HTTP method, response code, and upstream service. This is the most complete picture of what endpoints actually receive traffic.

If the API sits behind DigitalAPI's Helix Gateway, the traffic analytics dashboard gives you real endpoint usage data without digging through raw logs. You can see which paths are called, how often, and what response patterns look like.

Capture live traffic from the application: If the API powers a frontend application:

1. Open Browser DevTools, Network tab
2. Filter by Fetch/XHR
3. Perform every action the application supports: log in, load a record, submit a form, trigger an error
4. Record every unique API call: method, path, request headers, request body, response body

Export the complete capture. You now have a working inventory of the API's surface area.

Probe for common patterns: If none of the above works, try standard REST path patterns systematically:

# Try the root
curl -i https://api.example.com/

# Try /health or /status
curl -i https://api.example.com/health
curl -i https://api.example.com/status

# Try common resource names
curl -i https://api.example.com/v1/users
curl -i https://api.example.com/v1/accounts
curl -i https://api.example.com/v1/orders

# Check for version patterns
curl -i https://api.example.com/v2/users

A 401 or 403 is good news: it confirms the endpoint exists and requires auth. A 404 is ambiguous: it might not exist, or the path might be wrong. A 200 or 405 (method not allowed) confirms the path is valid.

Record everything. Even during discovery, maintain a running log of every endpoint you find:

Phase 2: Validate Authentication

Authentication is the wall every undocumented API puts in front of you. The approach is to let the API's error responses tell you what it expects.

Send a request without any credentials:

curl -i https://api.example.com/v1/users

Read the response carefully. Look for:

• WWW-Authenticate: Bearer realm="api" → OAuth Bearer token expected
• WWW-Authenticate: Basic realm="api" → HTTP Basic Auth (username:password Base64-encoded)
• {"error": "api_key_required"} → API key in a header or query parameter
• {"error": "invalid_token"} → Token expected but none provided

Check response headers for clues about auth location:

curl -v https://api.example.com/v1/users 2>&1 | grep -i "auth\|key\|token\|bearer"

Test common API key header names:

# X-API-Key is the most common

curl -i -H "X-API-Key: test_key" https://api.example.com/v1/users

# Some APIs use Authorization with a custom scheme

curl -i -H "Authorization: ApiKey test_key" https://api.example.com/v1/users

# Some use a query parameter

curl -i "https://api.example.com/v1/users?api_key=test_key"

The error response when you provide the wrong key format is often different from when you provide no key at all. invalid_api_key vs missing_api_key confirms you've found the right header. Even a wrong key that returns 401 invalid_api_key confirms the auth mechanism.

Don't guess credentials in production: If you're testing against a production endpoint with no sandbox, keep test calls read-only (GET requests) until you've fully understood the auth scope. A write call to a production endpoint with partial credentials can trigger real transactions, charge real accounts, or expose data you're not cleared to access. If the API powers a regulated system (banking, insurance, healthcare), sandbox first. DigitalAPI's API sandboxing creates isolated testing environments for exactly this scenario, removing production risk entirely.

Phase 3: Probe Request and Response Schemas

Once you can authenticate, the next step is understanding what the API expects and what it returns.

Start with safe GET requests:

# List endpoint

curl -i -H "Authorization: Bearer TOKEN" https://api.example.com/v1/users

# Single resource endpoint

curl -i -H "Authorization: Bearer TOKEN" https://api.example.com/v1/users/1

Record the complete response body. Document every field:

Probe POST endpoints with minimal payloads. Start with an empty body and expand based on the error messages:

# Empty body - error should reveal required fields

curl -X POST \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{}' \
  https://api.example.com/v1/users

A good API returns a 400 with a specific error like {"error": "email is required"}. Work through each required field one at a time. The error messages themselves become your documentation.

Test edge cases to discover validation rules:

# String length

curl -X POST ... -d '{"email":"'"$(python3 -c "print('a'*300)")"'@example.com"}'

# Invalid format

curl -X POST ... -d '{"email":"not-an-email"}'

# Missing optional fields

curl -X POST ... -d '{"email":"test@example.com"}'

Error responses for invalid inputs reveal validation rules: maximum lengths, required formats, enum constraints, and field-level business logic. Document each one.

Phase 4: Test Functional Scenarios in Isolation

With auth validated and schemas mapped, you can now run functional scenarios. Always in a sandbox or test environment. Never explore write endpoints against production data for the first time.

Build a scenario matrix. Before writing requests, map the scenarios you need to cover:

Test the rate limit boundary by incrementing request frequency gradually:

# Quick rate limit probe using a loop

for i in {1..20}; do

  STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
    -H "Authorization: Bearer TOKEN" \
    https://api.example.com/v1/users)

  echo "Request $i: $STATUS"

  sleep 0.1

done

Watch for the response code to change from 200 to 429. Check the response headers at that point for Retry-After or X-RateLimit-* values. This tells you the burst limit and the reset window.

Check pagination behaviour if the list endpoint returns many records:

# Try standard pagination parameters

curl -i "https://api.example.com/v1/users?page=1&per_page=10" \
  -H "Authorization: Bearer TOKEN"

# Try cursor-based pagination

curl -i "https://api.example.com/v1/users?cursor=NEXT_CURSOR" \
  -H "Authorization: Bearer TOKEN"

# Try offset/limit

curl -i "https://api.example.com/v1/users?offset=0&limit=10" \
  -H "Authorization: Bearer TOKEN"

The pattern used becomes part of your documentation. Record which query parameters the API actually accepts vs which it ignores.

For banking and insurance platform teams: Undocumented APIs in regulated environments carry additional risk. A test call that triggers a real transaction, a compliance event, or an audit log entry creates exposure that is hard to explain. DigitalAPI's banking industry deployment specifically addresses this by providing isolated sandbox environments that mirror production API behaviour against mock data, so functional testing never touches live systems. This is not optional for PSD2, HIPAA, or DPDP-adjacent API estates.

Phase 5: Convert Findings to a Spec and a Sandbox

This is the phase that makes all previous effort permanent. Without it, you've done useful work that disappears when you close your terminal. The next engineer who needs this API starts from scratch.

Generate an OpenAPI spec from your findings. You have enough information now: endpoint paths, HTTP methods, request schemas, response schemas, error codes, and auth mechanism. Turn this into a structured OpenAPI 3.0 YAML file.

The minimum viable spec for an endpoint looks like this:

paths:
  /v1/users:
    get:

      summary: List users
      description: Returns a paginated list of users. Supports page and per_page query parameters.

      security:
        - bearerAuth: []

      parameters:

        - name: page
          in: query
          required: false
          schema:
            type: integer
            default: 1

        - name: per_page
          in: query
          required: false
          schema:
            type: integer
            default: 20
            maximum: 100

      responses:

        '200':
          description: Successful response

          content:
            application/json:
              schema:
                type: object
                properties:

                  data:
                    type: array
                    items:
                      $ref: '#/components/schemas/User'

        '401':
          description: Missing or invalid credentials

        '429':
          description: Rate limit exceeded

Do this for every endpoint you've mapped. The spec file becomes the single source of truth.

Use traffic-based generation if manual spec writing is too slow. For APIs with 20+ endpoints, writing the spec by hand is laborious. Tools like Levo.ai and Treblle can observe live API traffic and auto-generate an OpenAPI spec from real request/response pairs. For teams already on DigitalAPI, the API management platform ingests specs from multiple sources and can generate documentation from the reverse-engineered spec immediately.

Publish to a portal. Once you have an OpenAPI spec, DigitalAPI's API documentation solution auto-generates an interactive reference page, connects it to a sandbox, and publishes it through a searchable API developer portal. The next engineer who needs this API finds it in the catalog with documentation, test credentials, and a working sandbox. The cycle of reverse engineering the same undocumented API ends.

For the full build process from spec to published portal, see how to build an API documentation portal.

Common Mistakes When Testing Undocumented APIs

1. Testing write endpoints in production first:

Always start with GET requests. Always confirm auth scope before attempting POST, PUT, or DELETE. An accidental write to a production endpoint you don't understand can trigger a real transaction, a notification, a billing event, or a cascading state change that's hard to reverse.

2. Assuming endpoint names describe behaviour:

‍/v1/users/archive might mean soft-delete, hard-delete, move to archive state, or something entirely different based on business logic. Test before assuming. The error responses and the actual effect on the resource tell you what the endpoint does.

3. Skipping rate limit discovery:

An undocumented API with an undiscovered rate limit will hit you in production integration testing at the worst possible time. Always probe rate limits explicitly before building any integration that loops over endpoints.

4. Treating discovery as the end goal:

The point of testing an undocumented API is not to confirm it works. It's to produce a documented, specced, sandboxed API that the next person doesn't have to reverse-engineer from scratch. Every hour spent on discovery that doesn't produce a spec file is an hour that will be spent again by someone else.

5. Ignoring versioning signals:

Check response headers for API-Version, X-API-Version, or version identifiers in the path (/v1/, /v2/). If you're integrating against v1 and v2 exists, your integration will break when v1 is deprecated. Check for a changelog or deprecation notice at /changelog, /release-notes, or in the response headers.

If you're a platform engineer dealing with undocumented APIs across multiple gateways and the answer isn't "test it with curl and document it manually," DigitalAPI's API governance layer discovers shadow APIs across your gateway estate, flags undocumented endpoints, and initiates the spec generation workflow automatically. The manual reverse-engineering cycle described in this guide becomes the fallback, not the default. See how it works.

From Undocumented to Production-Ready: The Governance Path

Testing an undocumented API successfully is step one. The enterprise outcome is converting that API from a shadow risk into a managed, discoverable, governed asset.

The path looks like this:

Discover: Surface the API through gateway logs, traffic inspection, or DigitalAPI's API discovery catalog. Know that it exists and where it runs.

Test: Follow the five-phase workflow above. Map the surface, validate auth, probe schemas, test functional scenarios, discover rate limits and pagination.

Document: Convert observations into an OpenAPI spec. Auto-generate documentation from the spec. Enrich with human context: what the API does, what problems it solves, error handling guidance. For what external-facing documentation should include, see external API documentation best practices.

Sandbox: Publish the API to a governed sandbox environment. Other developers can test against it without production risk. DigitalAPI's API sandboxing creates isolated environments directly connected to the portal.

Govern: Apply security scanning, OWASP checks, and documentation completeness audits via the governance layer. The API gets a compliance status, an owner, and a lifecycle stage.

Publish: The API appears in the developer portal with documentation, sandbox access, and an access request workflow. It becomes a reusable asset, not a recurring discovery problem.

DigitalAPI tracks this transition through API analytics, showing usage, latency, error rates, and documentation engagement for every API in the catalog, including the ones that started as undocumented shadow APIs.

Frequently Asked Questions

1. How do you test an API without documentation?

Use curl or browser DevTools to discover endpoints, validate auth from error responses, then probe schemas with controlled incremental calls.

Start by checking for a hidden spec file at /openapi.json or /swagger.json. If none exists, use browser DevTools to capture live API calls from the application, or send controlled cURL requests starting with GET to visible-looking paths. Read every error response: a 401 tells you auth is required, a 400 with field errors tells you the required schema. Document everything as you go and convert findings to an OpenAPI spec.

2. How do I test an API without Postman?

cURL works on any machine with no install. Browser DevTools captures live calls. HTTPie adds readable output. Hoppscotch needs no install at all.

cURL is pre-installed on macOS and Linux. Browser DevTools needs no install and captures real API calls from web applications. HTTPie adds readable syntax and pretty-printed JSON for interactive terminal exploration. Hoppscotch runs in any browser with no account required. Bruno is the Git-friendly desktop option for teams building persistent test collections. Each covers the full workflow that Postman handles, without the cloud sync, account requirement, or paid tier restrictions.

3. What is the best way to discover undocumented API endpoints?

Check for hidden spec files first, then use browser DevTools to capture live calls, then probe gateway logs for routed paths.

The fastest path is a hidden spec file: try /openapi.json, /swagger.json, /api-docs, and /v1/openapi.yaml. If none exist, open browser DevTools and capture every network request the application makes. For internal enterprise APIs, gateway access logs show every routed path with HTTP method and response code. Platform teams with DigitalAPI's API discovery get a catalog view of every endpoint across all connected gateways without manual log inspection.

4. Can I reverse-engineer an API from live traffic?

Yes. Browser DevTools and proxy tools like mitmproxy capture request and response pairs that reveal endpoint paths, schemas, and auth patterns.

Browser DevTools is the simplest approach for web-backed APIs: filter the Network tab by XHR/Fetch, trigger every action in the application, and export captured requests. For mobile apps or backend-to-backend APIs, a proxy tool like mitmproxy or HTTP Toolkit intercepts HTTPS traffic and shows the full request/response cycle. Traffic-based spec generation tools like Levo.ai and Treblle take the captured traffic a step further and automatically produce an OpenAPI spec from observed call patterns.

5. What should I do after testing an undocumented API?

Convert your findings into an OpenAPI spec, publish it to a sandbox and developer portal, and assign an owner so the cycle doesn't repeat.

Testing is only valuable if it produces a permanent artefact. Convert your endpoint map, schema observations, and error code findings into an OpenAPI 3.0 spec. Feed that spec into a documentation generator to produce interactive reference documentation. Publish the API through a developer portal with sandbox access and access controls. Assign an owner. Apply governance checks. The API moves from a shadow risk to a managed asset. DigitalAPI's API documentation solution handles the generation, portal publishing, and sandbox provisioning from a single spec file.