The mid-1990s “API” wasn’t called an API (but it acted like one)

In the mid-1990s, many web teams built integrations by exposing URLs that accepted input and returned output—often as HTML, sometimes as plain text, occasionally as structured-ish key/value formats. The mechanism varied, but the pattern was familiar:

• Client submits data via an HTML form or query string.
• Server processes the request in a CGI program (often Perl or C).
• Server returns a response that the browser renders or that another script parses.

That is, functionally, an API. Not a polished developer platform with SDKs and rate limits—but an endpoint-driven interface for automation.

By the time HTML 4.0 was published by the W3C in the late 1990s, the building blocks for structured web interactions were becoming more standardized, especially around forms and how browsers should submit input. (For reference, see the W3C’s HTML 4.0 specification: https://www.w3.org/TR/html40/.)

Browser scripting (1995-ish): automation moves closer to the user

JavaScript emerged in the mid-1990s and quickly became a way to add logic to pages: validate forms before submission, show/hide fields, and assemble slightly more dynamic requests. This mattered for early web “APIs” because it let developers:

• Reduce server load by catching invalid input before it reached the CGI script.
• Normalize payloads (for example, ensuring required fields were present).
• Create repeatable client-side flows that acted like a primitive “integration UI.”

From the perspective of web API history, this is an early hint of something that GitHub API users now do constantly: build a thin automation layer that orchestrates calls to server endpoints. The difference is that, in the 1990s, the “client automation” often lived directly in the browser, tightly coupled to a specific page and user session.

CGI scripts: the original “endpoint per action” design

CGI (Common Gateway Interface) became a workhorse for dynamic web pages. In practice, many sites ended up with a directory full of scripts whose names described actions:

• /cgi-bin/submit_bug.cgi
• /cgi-bin/add_comment.cgi
• /cgi-bin/build_status.cgi

That naming scheme should feel familiar to anyone who has scanned modern API endpoints. A lot of early automation amounted to “call this script with these parameters.” Even though the response might be HTML, another program could still consume it—especially if the output included predictable markers.

Here’s the historical connection to GitHub-style workflow automation: modern GitHub API usage also tends to map user-intent to endpoints—create an issue, label an issue, request a review, update a status. CGI-era design reinforced the idea that the web can be controlled by remote procedure-like calls over HTTP.

HTML forms: early payload design and the roots of JSON thinking

Forms were the payload mechanism most developers could rely on. A form submission encoded a set of fields—effectively a structured message. Developers learned quickly that payload design matters:

• Field names become your API contract (rename one and clients break).
• Optional vs. required inputs needs to be explicit.
• Repeated fields (like multiple labels) need a clear representation.

That’s the same set of issues API designers handle today, just with different tooling. Where modern GitHub API consumers send JSON like {"labels":["bug","triage"]}, a 1990s form might send label=bug&label=triage.

Even the developer experience problems rhyme. In 1995–1998, a common pain point was ambiguity: does the server accept GET or POST? What is the maximum field length? What happens on error? That pressure pushed teams toward clearer documentation and more predictable responses—precisely the kind of expectations that later made public web APIs viable at scale.

Authentication in 1995–1998: cookies, sessions, and the “token” idea before tokens

Modern GitHub automation is usually powered by tokens: personal access tokens, GitHub Apps, and other scoped credentials. In 1995–1998, authentication was more ad hoc, but the underlying concept was still “a secret that proves who you are.”

Common approaches included:

• HTTP Basic Authentication (simple, widely supported, and easy to script—also easy to misuse).
• Cookie-based sessions, increasingly normalized as browsers matured (cookie specs evolved in the late 1990s).
• Hidden form fields used as crude session identifiers (fragile, but common).

This era taught an enduring web API lesson: automation and authentication are inseparable. As soon as you make an action callable via a URL (like a CGI script), you need a way to ensure only authorized callers can trigger that action. GitHub’s modern permission scopes and app installations are a refined continuation of the same pressure.

Eventing before webhooks: polling, cron jobs, and email as an integration bus

GitHub workflow automation today often relies on webhooks: “something happened; here’s a POST request with the details.” In 1995–1998, real-time server-to-server callbacks were less common in typical web stacks, so teams leaned on alternatives:

• Polling: a script repeatedly requests a URL to check whether something changed.
• Cron-driven automation: scheduled tasks run every few minutes to sync state.
• Email notifications: systems send mail when an event occurs; another system parses the mail.

Polling may feel inefficient, but it shaped API design in an important way: it pushed teams to create endpoints that could answer “what’s new since X?” That idea still exists in modern API pagination, timestamps, and incremental sync patterns.

1998 and the rise of structured data: XML nudges the web toward machine readability

By 1998, XML 1.0 had arrived as a W3C recommendation, and it helped legitimize the idea that the web was not just for documents, but also for structured messages meant for machines. While XML isn’t required to tell the story of web APIs, it’s a crucial bridge between form posts and the JSON-first API world that GitHub would later exemplify.

In practical terms, teams started to see value in returning data that wasn’t “HTML for humans.” Even if many sites remained HTML-centric, the direction of travel was clear: automation thrives when responses are consistent, parseable, and stable.

So where does the GitHub API fit if GitHub didn’t exist yet?

GitHub (and its API ecosystem) is best understood as a highly refined expression of patterns that were already emerging in 1995–1998:

• Endpoints as verbs: CGI scripts for actions became API routes for actions.
• Payload discipline: form field naming conventions evolved into documented schemas.
• Authentication: Basic auth and sessions evolved into scoped tokens and app identities.
• Automation loops: cron polling evolved into event-driven webhooks and pipeline triggers.

What changed wasn’t the fundamental idea of web-based automation; it was the reliability, standardization, and developer-first packaging.

If you build automations today—whether you’re labeling issues, syncing release notes, or coordinating CI—your toolchain stands on decades of incremental improvements in how the web carries intent from one system to another. If you’re interested in practical, modern examples of automation patterns and how to operationalize them safely, you can explore more at https://automatedhacks.com/.

Key takeaways for modern API builders (learned the hard way in 1995–1998)

1. Stability matters more than elegance. Early integrations broke when parameters changed; modern APIs learned to version and document.
2. Make errors machine-readable. CGI scripts often responded with generic HTML errors; automation needs structured failure modes.
3. Expect automation to scale beyond your UI. A form is not just a form—it’s a contract other systems may depend on.
4. Security is part of the interface. If an endpoint triggers work, access control is not optional.

FAQ

Were there “web APIs” in 1995–1998?

Yes, even if teams didn’t always use the term. Many sites exposed URL-accessible endpoints via CGI and accepted structured input through query parameters or form submissions—functionally an API.

How is an HTML form related to a modern API request?

Both are structured messages sent over HTTP. A form submission is essentially a key/value payload. Modern APIs often use JSON instead, but the design concerns—field names, required inputs, validation, and error handling—are the same.

Did webhooks exist in this era?

Webhook-style callbacks weren’t a common, standardized pattern for most developers yet. Automation more often relied on polling, scheduled jobs, and email-based notifications, which served a similar purpose with different tradeoffs.

What’s the main historical lesson for GitHub API automation?

GitHub-style workflow automation is a polished continuation of mid-1990s web integration patterns: endpoints that represent actions, structured payloads, authentication mechanisms, and event-driven (or event-simulated) coordination between systems.