Using AI to Turn Packet Captures into API Documentation

An All-Too-Familiar Scenario

An indie developer takes on a freelance project that involves integrating with a third-party system. There's no API documentation—the other side just tosses over one line: "Just capture the packets and you'll figure it out."

So you open Charles or Fiddler and start capturing. Two hours later, the capture file contains hundreds of requests: login, token refresh, list fetching, pagination, uploads... They all seem to be there, but when you actually need to use them, the problems pile up:

• Which requests are different calls to the same API? Which are one-off dirty data?
• The request headers are full of fields—which ones are required, which are for authentication, and which are tracking noise?
• The response structures are nested five or six levels deep, and whether the pagination parameters live in the body or the query can only be figured out by opening each request one by one to compare
• Next week you have to deliver a "readable document" to the client, and right now even you can't understand it

That's exactly what the gig I took last month looked like. A conservative estimate: manually organizing this batch of captured data would take one to two days, and by the latter half, you'd get increasingly frustrated—missing fields and pasting wrong examples become the norm.

This time I tried a different approach: hand the exported capture data directly to AI for organizing. The result: what was "estimated at two days" became "half an afternoon," and the documentation quality was more standardized than what I would have written by hand.

What the AI Actually Did for Me

Let me be clear about the boundaries: AI is not there to "capture packets for you"—you still have to do the capturing yourself. What AI does is the most time-consuming dirty work that comes after:

1. Deduplication and grouping. The same API gets called thirty times with different parameters. The AI groups requests with the same path and method together, picks the most representative one as the baseline example, and flags parameter differences—for example, some calls have an extra debug=1, which is test-environment noise.

2. Field inference. For Authorization and X-Trace-Id in request headers, or sign and timestamp in the request body, the AI can judge from naming and value patterns that they're most likely authentication, signature, or tracing fields, and annotate them in the documentation as "inferred purpose, confirm with the API provider." Note that it marks inferences as such, rather than pretending to be 100% certain.

3. Structured output. Each API gets organized into a uniform format: API name, method, path, request parameter table (field/type/required/description), response structure, examples. Output directly as Markdown—paste it into Yuque or Notion and it's ready to deliver.

4. Catching what's missed. One paginated API's response contained a cursor field that I completely overlooked when reviewing manually. While organizing, the AI proactively pointed out: "This field appears in the query of subsequent requests; inferred to be a pagination cursor." Details like these are easy to miss when a human has to eyeball hundreds of requests.

My Specific Workflow

The whole process has four steps, none of which requires skills beyond basic technical literacy:

Step 1: Export to a text format. Use Charles's File → Export Session, choose HTTP Archive (.har), or just copy in RAW format. HAR is standard JSON, which AI reads most comfortably. If the data volume is large, process it in batches—feeding in one or two hundred requests at a time is enough.

Step 2: Sanitize sensitive data. Do not skip this step. Tokens, phone numbers, internal IPs, real names—search and replace them with placeholders yourself first. My usual practice is to globally replace Bearer xxx with Bearer <TOKEN>. This protects data security and also makes AI processing more stable.

Step 3: Apply a prompt template. This is the version I've stabilized after iterating across several projects—copy and use directly:

你是一名后端接口文档工程师。我会提供抓包导出的 HTTP 请求记录(HAR 格式或 RAW 文本),
请帮我整理成规范的接口文档,要求:

1. 归并:将相同方法+路径的请求合并为一个接口,挑选一条参数最完整的作为示例;
2. 噪音识别:标记出疑似测试、重试、埋点类的请求,单独列出,不混入正式接口;
3. 字段分析:为每个请求参数和响应字段标注【类型】【必填/选填(推测)】【说明(推测)】,
   推断不确定的字段明确写"待与接口方确认",不要编造;
4. 输出格式:每个接口包含——接口名称(根据路径和语义命名)、请求方法、完整 URL、
   请求头(仅保留关键头,说明用途)、请求参数表格、响应结构表格、一条完整示例(已脱敏);
5. 最后附一节"存疑清单":列出所有你不确定、需要人工确认的点。

以下是抓包数据:
[粘贴数据]

Step 4: Human review. Focus on the "open questions list"—take the fields the AI marked as "to be confirmed" to the API provider, or verify them yourself by capturing a few more packets. Don't skip this step—what AI organizes is "what can be seen from the data"; business semantics still need a human gatekeeper.

Before and After: Doing the Math

Using my recent project as a reference (about 300 captured records, organized into 22 APIs):

That's roughly a tenfold difference in time, but two implicit factors matter more than time:

First, quality consistency. After four hours of manual organizing, attention inevitably declines—missing fields and wrong examples are almost guaranteed. AI doesn't get tired; API #22 has exactly the same format as API #1.

Second, upfront review costs. The biggest problem with purely manual organizing is that "you don't know what you've missed." The AI's open questions list explicitly surfaces all uncertain points, turning review into a checklist-driven inspection task rather than a game of chance.

On cost: processing this volume of data with a mainstream large model typically costs on the order of a few yuan to a few dozen yuan per run—check each provider's official pricing page for specifics. Compared to the person-day saved, you don't need an actuary to do this math.

A Few Practical Tips

• Sanitization takes priority over everything. Production capture data contains everything—replace sensitive values before uploading.
• Don't feed in too much at once. Process hundreds of requests in batches, have the AI output a section per batch, then merge at the end—this is more stable than stuffing everything in at once.
• Don't take the numbers in my example as gospel. My comparison table is based on a single real project of mine. Your data volume and API complexity will differ, so the numbers will vary—but the order-of-magnitude difference generally holds.
• Keep the AI's inference annotations in the documentation. Clean up the "to be confirmed" fields before delivery—don't let inferences slip into the official documentation.

Final Thoughts

The scarcest resource for indie developers and small teams is uninterrupted blocks of time. Work like organizing packet captures is low in technical difficulty yet astonishingly time-consuming—precisely one of the scenarios where AI assistance offers the best ROI. Redeeming an afternoon from drudgery and spending it writing actual business code is a trade that pays off no matter how you calculate it.

If you don't yet have a stable AI API resource, or want to make this kind of documentation work part of an automated workflow in your projects, you can try this platform: https://api.thistoken.ai/register —sign up to access mainstream large models and get the workflow above up and running.

---

Ready to try it yourself? Sign up at https://api.thistoken.ai/register to get your API key and start building.