The Severed Function
Unlike Ecosystem Extinction (Type 1 Umbrabyte), which kills an entire platform, API Petrifaction is surgical: it kills specific functions within otherwise living artifacts.
Imagine a 2008 blog post that's perfectly readable—the text renders fine, the images load. But there's a gray box where an interactive Google Maps widget used to be. The error message: "API Key Invalid."
The blog post is a Vivibyte. The embedded map is an Umbrabyte. This is API Petrifaction.
How It Happens
The Web 2.0 Architecture
In the mid-2000s, Web 2.0 introduced "mashup culture"—combining services from multiple providers into a single page:
- Embed a Google Map to show store locations
- Pull in Twitter feeds via API
- Display Flickr photo galleries with JavaScript widgets
- Add Facebook Like buttons and comment sections
- Use YouTube embeds for video hosting
This was celebrated as innovation: you didn't need to build everything yourself. Just call external APIs and stitch together functionality.
The Hidden Dependency
Every API call is a dependency—your site relies on someone else's infrastructure to function. This creates three vulnerabilities:
1. Deprecation
Companies release new API versions and sunset old ones. Your 2010 site uses Maps API v2; Google now only supports v3. Result: your map breaks.
2. Key Revocation
API keys expire, get rate-limited, or require re-registration. If you don't maintain them, embedded functions stop working.
3. Service Shutdown
The company kills the entire service (Google Reader, Twitter's free API tier, various analytics platforms). Your embedded widgets die instantly.
Canonical Examples
Google Maps Embeds (2008-2013)
Thousands of blogs and business sites embedded Google Maps using the old API. When Google migrated to a new version and deprecated old keys:
- Sites that weren't actively maintained showed blank gray boxes
- "For development purposes only" watermarks appeared
- Maps simply failed to load
The blog post text (Vivibyte) is fine. The map (Umbrabyte) is fossil evidence of a service that changed.
Twitter Widgets (2012-2020)
Early Twitter offered embed codes for "Latest Tweets" widgets. Sites proudly displayed their live Twitter feeds. Then:
- Twitter deprecated the old widget API
- New embeds required different code and rate limits
- Many old embeds just showed error messages or nothing at all
GameSpy Multiplayer (1999-2014)
Hundreds of PC games used GameSpy for multiplayer matchmaking. The games themselves (exe files) are Vivibytes—they still run. But the multiplayer function is an Umbrabyte:
- When GameSpy shut down in 2014, matchmaking servers went offline
- Games could no longer find opponents or host matches
- Single-player works; multiplayer is petrified
Flash Video Players (2000-2020)
Before HTML5 video, sites embedded Flash-based video players. When Adobe killed Flash in 2020:
- Old blog posts with embedded videos showed blank rectangles
- Educational sites with Flash tutorials became unusable
- The HTML around the video (Vivibyte) is fine; the player (Umbrabyte) is dead
The Brittleness of Web 2.0
API Petrifaction reveals a fundamental architectural problem:
Black Box Dependencies
When you embed a widget, you're including a black box you don't control:
- You don't host the code
- You don't know when it will change
- You can't fix it if it breaks
- You depend on someone else's maintenance commitment
The Tethered Function
This connects directly to Zittrain's "Generative vs. Tethered" framework. An embedded API is a tethered function:
- It requires ongoing connection to the service provider
- The provider can modify or kill it remotely
- You have no autonomy—you're at the mercy of the vendor
Compare to a self-hosted image (generative): you control the file, the server, the lifespan. It works as long as you maintain it.
Dependency Risk Realized
In systems architecture, "dependency risk" is the danger that your system will fail when a dependency fails. API Petrifaction is dependency risk made visible:
- The 2008 blog didn't fail because of bad code
- It failed because Google changed their Maps API
- The blogger didn't make a mistake—they made a dependency choice
Digital Scar Tissue
API Petrifaction creates "scar tissue" across the web—visible remnants of healed wounds:
- Blank gray boxes where maps used to be
- Broken "Share on Facebook" counters
- 404 errors from dead CDN links
- "This plugin is no longer supported" notices
Each scar is a fossil: evidence that a function once lived here, but died when its dependency was severed.
Other Manifestations
Link Rot
A specific form of API Petrifaction: shortlinks (t.co, bit.ly) that depended on redirect services. When those services change or die, the links break.
CDN Dependency
Sites that loaded jQuery or Bootstrap from external CDNs (Content Delivery Networks). If the CDN changes the file path or shuts down, the site's JavaScript breaks.
Comment Systems
Sites using Disqus, Facebook Comments, or Google+ comments. When those services change APIs or shut down (Google+), the comment threads vanish or become read-only.
Analytics Scripts
Embedded Google Analytics, StatCounter, or other tracking scripts. When the service updates its code, old sites may display warnings or broken functionality.
Prevention Strategies
Self-Host Dependencies
Instead of calling external APIs, host the resources yourself:
- Download library files (jQuery, fonts) to your server
- Host your own images instead of hotlinking
- Use static map images instead of interactive embeds
Graceful Degradation
Design so that if external dependencies fail, the core content remains usable:
- Provide text descriptions alongside interactive maps
- Include fallback content for video embeds
- Don't make navigation dependent on external scripts
Monitor and Maintain
Actively check for deprecated APIs and update accordingly. This requires ongoing labor—sites aren't "done" when published.
Use Open Standards
Prefer standards over proprietary services:
- HTML5 video instead of Flash
- Standard image formats instead of proprietary viewers
- RSS feeds instead of platform-specific widgets
The Archaeological Perspective
Reading the Scars
When excavating old sites with API Petrifaction, archaeologists can:
- Identify what services were popular (Facebook Like buttons everywhere = 2010-2015 era)
- See what dependencies failed (broken Google Maps = pre-2013)
- Understand the mashup culture of Web 2.0
- Document which services survived and which died
Fossils of Trust
API Petrifaction shows what services people trusted. Embedding Google Maps meant trusting Google to maintain the API. When that trust was broken (through deprecation), it left fossil evidence.
Field Notes
The Hotlinking Lesson: API Petrifaction has a simpler ancestor: hotlinking images from other sites. In the 2000s, forum users would hotlink images from Photobucket or ImageShack. When those services changed policies or shut down, millions of forum posts showed broken image icons. Same principle: dependency on external resources you don't control.
The jQuery CDN Debate: Developers debate whether to use Google's jQuery CDN or self-host. CDN argument: faster load times, shared caching. Self-host argument: no dependency risk. API Petrifaction evidence favors self-hosting—sites using Google's CDN work until Google changes the path.
The Wayback Machine Can't Always Help: The Internet Archive captures HTML, but often can't replay API calls—they require live servers. A snapshot of a 2010 blog shows the HTML for a Google Maps embed, but the map itself is just gray space. The fossil is preserved, but the living function can't be revived.
Contrast with Ecosystem Extinction
API Petrifaction differs from full Ecosystem Extinction:
- Scope: API Petrifaction kills specific functions; Ecosystem Extinction kills entire platforms
- Host Survival: The main artifact survives API Petrifaction; in Ecosystem Extinction, the host platform dies
- Visibility: API Petrifaction creates visible scars (broken widgets); Ecosystem Extinction requires mirrors to be visible at all
Both create Umbrabytes, but through different mechanisms.