When people say “web API,” it’s easy to picture neat JSON endpoints, interactive documentation, and a predictable lifecycle. But in the mid-to-late 1990s, web integration looked very different. In many organizations, the most important “APIs” weren’t officially called APIs at all—they were CGI scripts, HTML forms, querystring conventions, and bits of browser scripting that quietly moved data between systems.

This chapter (78 in a longer timeline) focuses on a specific historical tension: enterprise API discovery before there were widely adopted, web-native service descriptions. WSDL—which would later formalize how a service describes its operations and messages—did not exist yet in 1995–1998. Still, the exact pain WSDL aimed to solve was already visible: enterprises needed a reliable way to find, understand, and integrate with remote capabilities without relying on tribal knowledge.

1995–1998: “API Discovery” Meant Reading Source, Sniffing Traffic, or Calling the Developer

In 1995–1998, the web’s most common integration mechanisms were simple and human-oriented:

• HTML forms that submitted key/value pairs via GET or POST
• CGI programs that translated those parameters into database queries, emails, or internal actions
• Server-side scripts (often vendor- or platform-specific) that generated dynamic pages
• Early browser scripting that validated fields, changed form values, or triggered navigation flows

These pieces formed a kind of informal interface. If you knew that a form field named customer_id must be present, that action=lookup changed behavior, and that a hidden parameter toggled “internal mode,” you could integrate. But that knowledge rarely lived in a stable contract. It lived in:

• Emails and hallway conversations
• Comments in scripts
• Copied-and-pasted HTML from existing pages
• Homegrown “integration guides” that went stale quickly

This is the earliest flavor of enterprise API discovery on the web: not discovery through registries or machine-readable descriptions, but discovery through observation and reverse-engineering.

HTML Forms as Proto-APIs: The Contract Was the Markup

A surprising amount of early web integration was built on a practical truth: if a user can submit a form, a program can submit it too. Teams inside an enterprise learned to treat certain endpoints as stable “interfaces,” even if they were originally designed for interactive use.

That created a set of implicit rules—an unwritten contract:

• Parameters: names, allowed values, and defaults
• Encoding: how special characters were represented
• Session behavior: cookies or query parameters that had to be preserved
• Response parsing: scraping a success message out of HTML

Enterprises discovered these “APIs” by looking at the form HTML, watching what the browser sent, and mimicking it. The challenge is obvious in hindsight: HTML was designed for presentation, not for durable machine contracts. A small redesign could break an entire integration.

Browser Scripting and the Rise of Hidden Interfaces

As JavaScript became a practical tool for web authors in the late 1990s, it changed how integrations behaved. Scripts could populate hidden fields, build querystrings, and enforce validation rules that weren’t visible in the static markup.

For enterprise integrators, this introduced a new discovery problem: the “real” interface might be distributed across:

• HTML form elements
• JavaScript logic that rewrote or supplemented submitted values
• Server-side CGI expectations that were never documented publicly

In other words, the web page itself became a moving target. You could no longer rely on “view source” alone; you had to understand execution and side effects. Even when a team tried to be careful, the interface was still optimized for browsers, not for other programs.

CGI Endpoints and Early Dynamic Integration: Powerful, but Underspecified

CGI was one of the workhorses of early dynamic web development. It provided a straightforward way to receive HTTP requests and emit dynamic responses. In practice, CGI scripts frequently became integration hubs:

• A request came in via GET/POST.
• The script performed business logic (often database calls).
• The script returned HTML (and sometimes a file download).

The missing piece was a standardized description of what the endpoint did. A CGI “API” might have multiple modes controlled by parameters, and the response might vary depending on who called it or what cookies were present.

Enterprises handled discovery with strategies that feel familiar today, just far more manual:

• Endpoint inventories on internal wiki pages or shared documents
• “Known-good” request templates copied from one system to another
• Gatekeeper developers who answered questions and approved parameter changes

It worked—until it didn’t. Every integration added more pressure to formalize interface behavior.

Why Enterprises Cared About “Discovery” Before They Had the Words for It

By 1995–1998, many organizations were already running internal networks and early intranets where web interfaces sat in front of critical business systems. As usage grew, so did the need for reuse: teams wanted a single “customer lookup,” “order status,” or “inventory check” capability that could serve multiple applications.

The enterprise problem wasn’t just calling a URL. It was knowing:

• What operations exist?
• What inputs do they require?
• What outputs do they return?
• What errors can occur?
• How do you authenticate and handle sessions?

Those questions are exactly what later service-description approaches attempted to answer in a consistent, machine-readable way. The desire for “discovery” was real; the tooling was not.

1998 and XML: A Turning Point for Machine-Readable Contracts

In the late 1990s, the web community increasingly experimented with structured data formats beyond HTML. When XML became a W3C Recommendation in 1998, it gave enterprises something they could rally around: a text-based, widely implementable way to represent structured information.

The immediate impact wasn’t “suddenly we have modern APIs.” Instead, XML helped teams imagine a missing layer between “a URL you call” and “a business capability you can integrate safely.” If messages could be structured, then descriptions of those messages could be structured too.

That shift—toward describing interfaces with explicit types, operations, and message formats—sets the stage for WSDL even though WSDL itself arrived later.

Where WSDL Fits (Later): Naming the Contract and Enabling Discovery at Scale

It’s important not to rewrite history: WSDL was introduced after this 1995–1998 window. But if you’re studying web API history chronologically, you can see WSDL as an answer to the exact integration chaos enterprises encountered during this period.

WSDL’s core promise was straightforward: a service should be able to publish a formal description of what it offers—operations, inputs, outputs, and bindings—so that tools and teams can integrate with less guesswork. That’s a very different world from “inspect the form, replicate the POST, scrape the HTML response.”

For readers who want the primary specification text, the W3C publication is the most authoritative starting point: WSDL 1.1 (W3C Note).

Enterprise API Discovery Lessons That Started in 1995–1998 (and Still Matter)

This era left a few enduring lessons that show up in every generation of APIs:

1. Interfaces emerge before standards do. Enterprises will integrate with whatever is available—forms, scripts, files—long before a clean API contract exists.
2. Human-readable isn’t enough for scale. A system can work with email-based discovery and “ask Bob” workflows… until the organization grows.
3. Presentation formats are unstable contracts. HTML makes a poor long-term integration boundary because it changes for visual reasons.
4. Discovery is a product problem, not just a protocol problem. Even with HTTP, teams needed searchable inventories, consistent naming, versioning, and ownership.

Modern teams solving API documentation, cataloging, and governance challenges are working on a more advanced version of the same problem. If your current work involves inventorying endpoints or improving how teams find internal services, you’re revisiting a story that began with CGI scripts and form parameters.

For more practical explorations of automation and web-facing integrations, you can also browse Automated Hacks.

FAQ: WSDL and Early Enterprise API Discovery

Did WSDL exist in 1995–1998?

No. In that period, most web integration relied on HTML forms, CGI scripts, and other ad hoc methods. WSDL came later as part of a broader push toward formally described web services.

How did enterprises “discover” APIs before service descriptions?

Discovery was mostly manual: reading HTML source, copying request patterns, reverse-engineering parameters, and sharing knowledge via internal documents and key developers.

Why were HTML forms effectively APIs?

A form submission defines inputs (field names and values) and targets (the action URL). Programs could mimic the browser and submit the same request, turning user-facing workflows into machine-driven integrations.

What changed around 1998 that made WSDL-style thinking possible?

XML’s standardization in 1998 strengthened the idea of structured, machine-readable messages on the web. Once messages can be structured, describing those messages and operations becomes much more feasible.