apiregen

Guide the user through capturing web traffic as HAR files for analysis.

Deep-dive into a specific endpoint, domain, or pattern in the loaded HAR data.

Phase 2 — MAPPING: Build rich sample sets across sessions. Differential analysis of endpoints, tokens, and response patterns.

Build the clustered API model and generate OpenAPI/AsyncAPI specs from captured HAR traffic.

Phase 1 — RECON: Analyze captured traffic to build a comprehensive context profile of the target site.

Expert in reverse engineering GraphQL APIs from captured traffic and JavaScript source bundles. Reconstructs schemas, extracts operations, maps fragment dependency graphs, discovers hidden mutations/subscriptions, and identifies real-time WebSocket subscription protocols. MUST BE USED PROACTIVELY whenever any of the following signals appear in captured traffic, recon output, or source bundles: - A single POST endpoint accepting `{"query": "...", "variables": {...}}` payloads — typically `/graphql`, `/_api/graphql`, `/api/graphql`, `/gql` - Operation strings starting with `query `, `mutation `, or `subscription ` in request bodies - GraphQL AST object literals in JS bundles: `kind:"Document"`, `kind:"OperationDefinition"`, `kind:"FragmentDefinition"` - Custom headers: `x-operation-name`, `x-operation-type`, `x-apollo-operation-name`, `x-apollo-operation-id` - Persisted queries: `documentId`, `sha256Hash`, `persistedQuery` fields in the request or query string - Client libraries: `@apollo/client`, `apollo-boost`, `urql`, `relay-runtime`, `graphql-request`, `@tanstack/react-query` with gql - Build-time codegen output: `graphql-codegen`, `relay-compiler`, `.graphql.ts` / `.gql.js` artifacts - Response envelope: `{"data": {...}, "errors": [...]}` shape - `__typename` fields appearing throughout response data - WebSocket subprotocols: `graphql-ws`, `graphql-transport-ws`, `subscriptions-transport-ws` (coordinate with websocket-specialist) <example> Context: User captured traffic from a site that uses GraphQL user: "The API uses GraphQL at /_api/graphql, I need to map all the operations" assistant: "I'll use the graphql-specialist agent to extract and catalog all GraphQL operations from your captures and source." <commentary> GraphQL endpoint identified, user wants operation mapping — trigger graphql-specialist. </commentary> </example> <example> Context: User has JS bundles and wants to find hidden mutations user: "I need to find all the bet placement mutations in the source code" assistant: "I'll use the graphql-specialist agent to search the JS bundles for mutation definitions." <commentary> User wants to discover mutations from source — graphql-specialist handles JS bundle analysis for GraphQL AST nodes. </commentary> </example> <example> Context: User wants to understand the GraphQL type system user: "Can you reconstruct the schema from the fragments?" assistant: "I'll use the graphql-specialist agent to build the type system from fragment definitions and response data." <commentary> Schema reconstruction from fragments is core graphql-specialist work. </commentary> </example>

Expert in reverse engineering REST APIs from captured traffic and source code. Maps endpoints, infers resource schemas, identifies pagination patterns, detects authentication mechanisms, and produces OpenAPI-style specifications. MUST BE USED PROACTIVELY whenever any of the following signals appear in captured traffic, recon output, or source bundles: - Distinct URL paths per resource with standard HTTP methods (GET/POST/PUT/PATCH/DELETE) - Versioned paths: `/api/v1/`, `/api/v2/`, `/rest/`, `/v3/` - REST envelopes: `{"data": [...], "meta": {...}}`, `{"results": [...], "next": "..."}`, HAL/JSON:API payloads - Pagination params: `offset`/`limit`, `page`/`pageSize`, `cursor`/`next_cursor`, `Link: rel="next"` headers - Auth headers: `Authorization: Bearer`, `X-API-Key`, OAuth `/oauth/token` flows - Client libraries: `axios`, `fetch`, `ky`, `got`, `superagent`, `@tanstack/react-query`, SWR, RTK Query - Retrofit/OkHttp annotations in decompiled APKs (`@GET`, `@POST`, `@Path`, `@Query`) - ASP.NET/Spring/Express/Rails/Django route conventions visible in source - OpenAPI/Swagger JSON in the traffic (`/swagger.json`, `/openapi.yaml`, `/api-docs`) - Content types: `application/json`, `application/xml`, `application/hal+json`, `application/vnd.api+json` <example> Context: User captured traffic from a REST API user: "Map all the API endpoints from the captures" assistant: "I'll use the rest-api-specialist agent to catalog all endpoints, parameters, and response schemas." <commentary> REST endpoint mapping is core rest-api-specialist work. </commentary> </example> <example> Context: User wants to understand pagination user: "How does the pagination work on the /api/v1/events endpoint?" assistant: "I'll use the rest-api-specialist agent to analyze the pagination pattern across captured requests." <commentary> Pagination analysis across multiple requests requires understanding REST conventions. </commentary> </example> <example> Context: User wants an OpenAPI spec from traffic user: "Generate a swagger spec from the captured traffic" assistant: "I'll use the rest-api-specialist agent to infer an OpenAPI specification from the captured requests and responses." <commentary> OpenAPI/Swagger generation from traffic is a core rest-api-specialist deliverable. </commentary> </example>

Expert in reverse engineering WebSocket-based APIs and real-time protocols. Identifies WS endpoints, decodes frame protocols (graphql-ws, socket.io, SignalR, STOMP, MQTT, custom binary), maps subscription topics, and documents connection lifecycle. MUST BE USED PROACTIVELY whenever any of the following signals appear in captured traffic, recon output, or source bundles: - HTTP upgrade handshake: `Upgrade: websocket`, `Sec-WebSocket-Key`, `Sec-WebSocket-Protocol`, `Sec-WebSocket-Version` - URLs using `ws://` or `wss://` schemes, or paths like `/ws`, `/socket`, `/realtime`, `/stream`, `/live`, `/hub` - Client libraries in source: `WebSocket(`, `new WebSocket`, `socket.io-client`, `io(`, `@microsoft/signalr`, `HubConnection`, `stompjs`, `mqtt`, `centrifuge`, `pusher-js`, `ably`, `phoenix` (LiveView/Channels), `sockjs` - Subprotocol strings: `graphql-ws`, `graphql-transport-ws`, `subscriptions-transport-ws`, `mqtt`, `v12.stomp` - Message envelopes: `{"type":"connection_init"|"subscribe"|"next"|"complete"}` (graphql-ws), `{"type":1,"target":"..."}` (SignalR), socket.io packet codes (`0`,`40`,`42[...]`), STOMP `CONNECT`/`SUBSCRIBE`/`MESSAGE` frames - Binary frame formats: Protobuf (`.proto` files, `@protobuf-ts/runtime`), MessagePack (`@msgpack/msgpack`, `msgpack-lite`), FlatBuffers, raw `ArrayBuffer`/`Blob` handling in WS listeners - Server-Sent Events as real-time alternative: `text/event-stream` responses, `EventSource` in source - Long-polling upgrade patterns: `/socket.io/?EIO=4&transport=polling`, SignalR `/hub/negotiate` - User mentions live/real-time data: live odds, live scores, chat, notifications, streaming feeds, bidirectional communication <example> Context: User needs to understand the WebSocket layer of a sports betting site user: "How do the live odds updates work? I think they use WebSockets" assistant: "I'll use the websocket-specialist agent to analyze the WebSocket protocol and map the subscription topics." <commentary> Real-time odds updates via WebSocket — websocket-specialist handles protocol identification and subscription mapping. </commentary> </example> <example> Context: User found WebSocket traffic in mitmproxy captures user: "I captured some WebSocket frames, can you decode them?" assistant: "I'll use the websocket-specialist agent to identify the protocol and decode the frame payloads." <commentary> WebSocket frame decoding requires protocol identification — websocket-specialist work. </commentary> </example> <example> Context: User wants to replicate a WebSocket subscription in their bot user: "I need to subscribe to market updates like the site does" assistant: "I'll use the websocket-specialist agent to document the connection handshake, subscription protocol, and message shapes." <commentary> Replicating WebSocket subscriptions requires understanding the full connection lifecycle. </commentary> </example>

Expert in identifying and decoding binary/opaque message payloads in captured traffic — base64, hex, gzip/deflate/brotli/zstd, MessagePack, CBOR, Protobuf, FlatBuffers, BSON, Avro, gRPC/gRPC-Web framing, and layered combinations of the above. Probes candidate codecs against real samples, validates that the decode produced structured data, and documents the exact decode chain needed to replay the payload in client code. MUST BE USED PROACTIVELY whenever any of the following signals appear in captured traffic, recon output, or source bundles: - Response/request bodies that are not valid UTF-8 text or parse as JSON but surface as gibberish in HAR viewers - Content-Type headers: `application/octet-stream`, `application/x-protobuf`, `application/protobuf`, `application/grpc-web`, `application/grpc-web+proto`, `application/msgpack`, `application/x-msgpack`, `application/cbor`, `application/bson`, `application/avro-binary`, `application/vnd.apache.thrift.binary` - Content-Encoding headers beyond identity: `gzip`, `deflate`, `br` (brotli), `zstd`, `compress` - Magic-byte prefixes in the first few bytes of a body: `1f 8b` (gzip), `78 9c`/`78 da`/`78 01` (zlib), `28 b5 2f fd` (zstd), `50 4b 03 04` (zip), `d4 c3 b2 a1` (pcap), Protobuf varint tag bytes (`0x08`–`0x7a`), MessagePack type bytes (`0x80`–`0x8f` fixmap, `0x90`–`0x9f` fixarray, `0xc0`–`0xdf` typed) - JSON fields whose values are long strings matching base64 (`[A-Za-z0-9+/=]`), base64url (`[A-Za-z0-9\-_=]`), or hex (`[0-9a-fA-F]{2}+`) patterns — especially fields named `payload`, `data`, `body`, `token`, `sig`, `blob`, `p`, `d` - Query string or form parameters carrying base64/hex blobs - WebSocket binary frames (`blob`/`arraybuffer` handlers) — coordinate with websocket-specialist - Source-code signals: `atob`/`btoa`, `Buffer.from(..., 'base64'|'hex')`, `pako` (gzip in JS), `fflate`, `@msgpack/msgpack`, `msgpack-lite`, `notepack.io`, `msgpack5`, `protobufjs`, `google-protobuf`, `@protobuf-ts/runtime`, `@bufbuild/protobuf`, `cbor-x`, `cbor-js`, `flatbuffers`, `bson`, `@grpc/grpc-js`, `grpc-web`, `@improbable-eng/grpc-web`, `TextDecoder('utf-8')` on `Uint8Array`, explicit `new Uint8Array(...)` decoding pipelines - Decompiled APK signals: `CodedInputStream`, `MessageNano`, `MessageLite`, `com.google.protobuf`, `org.msgpack`, `okio.GzipSource`, `okio.InflaterSource`, `Base64.decode`, `javax.xml.bind.DatatypeConverter.parseHexBinary` - User mentions: "binary payload", "can't read the response", "looks encoded", "gRPC", "protobuf", "MessagePack", "gzipped", "base64 blob" <example> Context: User finds a response body that looks like random bytes user: "The /api/stream endpoint returns binary — I can't tell what format it is" assistant: "I'll use the binary-decoder-specialist agent to probe the payload against common codecs and confirm the decode chain." <commentary> Unknown binary payload — binary-decoder-specialist is the right tool for systematic codec probing. </commentary> </example> <example> Context: JSON response contains a suspiciously long string field user: "The `payload` field in this response is a long opaque string — is it encrypted or just encoded?" assistant: "I'll use the binary-decoder-specialist agent to test whether it's base64, hex, or a layered encoding like base64(gzip(msgpack))." <commentary> Opaque string inside JSON is a classic layered-encoding case — specialist will peel the layers. </commentary> </example> <example> Context: WebSocket frames are binary, websocket-specialist needs help with frame payloads user: "The WS frames are binary and I found `@msgpack/msgpack` in the bundle" assistant: "I'll use the binary-decoder-specialist agent to confirm the MessagePack framing and document how to decode incoming frames." <commentary> Binary WS frames — websocket-specialist maps the protocol, binary-decoder-specialist owns the frame payload decoding. </commentary> </example>

Expert in reverse engineering gRPC, gRPC-Web, Connect, Twirp, and Protobuf-over-HTTP transports from HAR captures, mitmproxy flows, source bundles, and decompiled mobile clients. MUST BE USED PROACTIVELY whenever any of these signals appear: - Content types: `application/grpc`, `application/grpc+proto`, `application/grpc-web`, `application/grpc-web+proto`, `application/connect+proto`, `application/proto`, `application/x-protobuf` - Headers: `grpc-status`, `grpc-message`, `grpc-timeout`, `grpc-encoding`, `grpc-accept-encoding`, `connect-protocol-version`, `connect-timeout-ms`, `x-grpc-web` - Paths shaped like service methods: `/package.Service/Method`, `/twirp/package.Service/Method`, `/buf.connect.demo.Service/Method` - Source imports: `grpc-web`, `@grpc/grpc-js`, `@connectrpc/connect`, `@bufbuild/protobuf`, `protobufjs`, `google-protobuf`, `@protobuf-ts/runtime`, `twirp` - Mobile/decompiled signals: `io.grpc`, `ManagedChannel`, `ClientInterceptor`, `GeneratedMessageLite`, `MessageLite`, `okhttp` carrying `application/grpc` - Binary frames with 5-byte gRPC envelopes or trailers containing gRPC status metadata Coordinate with binary-decoder-specialist for raw Protobuf field probing when `.proto` descriptors are unavailable.