You want to stay current with Python programming news. NewsAPI aggregates articles from TechCrunch, Medium, and major tech outlets. The Guardian provides quality journalism and technology coverage. HackerNews surfaces what developers are actually discussing. Each source offers valuable perspectives, but querying three different APIs means writing three separate integrations, handling three different data structures, and managing three different error patterns.
This isn't unique to news aggregation. Your e-commerce platform needs both Stripe and PayPal. Your analytics dashboard combines Google Analytics with Mixpanel. Your authentication system supports GitHub, Google, and Microsoft OAuth. Production systems constantly face this challenge: multiple external services, each with its own response format, failure modes, and quirks. Yet your application needs unified, consistent data.
This chapter teaches you the systematic approach professionals use for multi-API integration. You'll build a news aggregator that queries three different sources simultaneously, normalizes incompatible response formats into a single internal representation, handles failures gracefully, removes duplicates intelligently, and presents unified results. By the end, you'll have a working command-line tool searching real APIs plus the architectural knowledge to integrate any collection of external services.
What Success Looks Like
Before diving into implementation details, see the completed aggregator in action. This preview shows what you'll build:
======================================================================
📰 NEWS AGGREGATOR
======================================================================
Search news from NewsAPI, The Guardian, and HackerNews
Commands:
search <query> - Search for news articles
more - Show more results from last search
group - Show last results grouped by source
help - Show this help message
quit - Exit application
======================================================================
aggregator> search python programming ↩
Searching for 'python programming'...
✓ NewsAPI: 5 articles
✓ Guardian: 5 articles
✓ HackerNews: 5 articles
======================================================================
📰 NEWS AGGREGATOR RESULTS
======================================================================
Query: 'python programming'
Sources: NewsAPI, Guardian, HackerNews
Articles: 12 (3 duplicates removed)
1. Python 3.13 Performance Improvements
📰 TechCrunch • January 15, 2025 at 02:30 PM
✍️ Sarah Chen
Python's latest release brings significant speed improvements...
🔗 https://techcrunch.com/2025/01/15/python-3-13-performance
(techcrunch.com)
... and 9 more articles
======================================================================
One search command queries three APIs simultaneously. All sources respond successfully (notice the checkmarks). Fifteen articles became twelve after automatic deduplication. Results display in consistent format whether they came from NewsAPI, Guardian, or HackerNews. The complexity of integrating three different APIs is completely hidden from users.
The Multi-API Challenge
Here's what makes this difficult: these three services represent the same concept (a news article) in completely different ways. NewsAPI wraps articles in an articles array with nested source objects. Guardian buries them in response.results using field names like webTitle and webPublicationDate. HackerNews uses hits with Unix timestamps and minimal metadata. Same business concept. Three incompatible structures.
Without a systematic approach, your codebase becomes a mess of conditionals. Display logic needs branching: "if NewsAPI show publishedAt, if Guardian show webPublicationDate, if HackerNews convert Unix timestamp..." Every operation—storage, sorting, deduplication, filtering—requires source-specific handling. This approach doesn't scale. Adding a fourth source means updating dozens of locations throughout your code.
Production systems need architecture that isolates API differences. You normalize external formats into one internal representation at the boundary, then everything downstream works with consistent structure. Display code never knows or cares which API provided the data. This separation makes systems maintainable as APIs evolve and requirements change.
Learning Objectives
What You'll Master in This Chapter
By the end of this chapter, you'll be able to:
- Systematically explore and document multiple API structures before writing extraction code
- Design canonical models that unify disparate API response formats into consistent internal representations
- Build source-specific normalizers that apply defensive programming patterns while handling each API's unique quirks
- Implement aggregation pipelines with graceful degradation that continue operating when individual sources fail
- Recognize the boundary between crash prevention (defensive programming) and quality enforcement (validation)
- Apply multi-API integration patterns that scale from two sources to twenty
The Professional Approach to Multi-API Integration
Chapter 10 taught you advanced JSON processing patterns in isolation: safe navigation through nested data, flexible extraction with extract_items_and_meta(), defensive handling of optional fields. This chapter shows you applying those patterns to solve a real architectural challenge.
You'll learn the five-step workflow professionals use for multi-API integration:
Explore Before Coding
Use diagnostic tools to discover actual API structures. Documentation is often incomplete or outdated. Exploration reveals the real response patterns, nesting depths, field names, and optional data your code must handle.
Design Canonical Models
Define one internal format that accommodates all sources. This becomes your application's "internal language." Choose field names once, decide on required versus optional fields once, standardize formats (timestamps, URLs) once.
Build Normalizers
Create functions that transform each API's quirks into your canonical format. Apply defensive patterns from Chapter 10: safe navigation, type checking, default values. Each normalizer handles one API's specifics while following a universal pattern.
Handle Partial Failures
Build systems that provide value even when components fail. When one API is down, return results from working sources. Track which sources succeeded and failed. Degrade gracefully rather than crashing completely.
Recognize Limitations
Understand where defensive programming stops being sufficient. Your system won't crash, but quality issues can slip through. Empty fields, malformed data, business rule violations—these need validation beyond defensive programming.
This systematic approach works whether you're integrating two APIs or twenty. The architecture applies to payment processors (Stripe + PayPal), analytics platforms (Google Analytics + Mixpanel), authentication providers (GitHub + Google + Microsoft), or any system requiring multiple external data sources. Master it once, apply it everywhere.
Production applications rarely depend on a single API. You'll integrate payment processors, authentication providers, analytics services, notification systems, and data sources. Each has its own response format, error patterns, and reliability characteristics. This chapter teaches you the systematic approach that scales from two APIs to twenty.
You'll also discover where defensive programming stops being enough. The aggregator will work—articles display, searches complete—but you'll encounter quality issues that defensive programming can't prevent. This chapter sets up Chapter 12's validation techniques by showing exactly what problems remain when you rely solely on defensive patterns.
What You'll Build
The news aggregator consists of five components, each demonstrating architectural patterns you'll use in production systems:
Exploration Tools
Diagnostic utilities that reveal how each API structures responses. Produce comparison tables showing where the same data lives in different APIs. Guide normalizer design with facts, not assumptions.
Canonical Article Model
A single Article dataclass representing news articles consistently, regardless of source. Defines required fields (title, URL, timestamp, source) and optional fields (description, author, image). This becomes your application's internal representation—its "common language."
Source-Specific Normalizers
Three functions transforming each API's unique response format into canonical model. Each applies Chapter 10's defensive patterns while handling API-specific quirks: field name mappings, nested structure navigation, timestamp conversions, optional field extraction.
Aggregation Pipeline
The orchestrator fetching from all sources independently, handling failures gracefully, deduplicating results, and sorting by recency. Demonstrates production patterns: graceful degradation (system works with 2 out of 3 sources), partial results (some data beats no data), and operational monitoring.
Interactive CLI
Command-line interface for searching, viewing results, and exploring articles. Demonstrates how canonical models simplify everything downstream: write formatting code once, works for all sources automatically. No conditional logic based on source.
The complete implementation (approximately 400 lines) appears in Appendix A. The chapter walks through architecture and design decisions, implementing key components while explaining the approach you'd apply to any multi-API integration. You'll understand not just what to build, but why each architectural choice matters.
Chapter Roadmap
This chapter builds a production-ready news aggregator by applying Chapter 10's patterns to real multi-API integration. Here's the journey:
Discovery & Design
Explore how three real APIs structure responses using diagnostic tools, then design the canonical Article model that unifies all sources into one clean internal format.
Core Implementation
Build source-specific normalizers transforming each API into canonical format, then implement the aggregation pipeline that handles failures gracefully and deduplicates intelligently.
Polish & Reflection
Create the CLI interface that makes canonical models shine, then examine where defensive programming reaches its limits—setting up Chapter 12's validation approach.
Appendix A contains the complete 400-line implementation for reference. The chapter focuses on architecture and design decisions you'll apply to any multi-API integration.
Prerequisites
This chapter assumes you've completed Chapter 10 and are comfortable with: exploration tools for discovering API structures, flexible access patterns using extract_items_and_meta() and safe_get(), safe navigation through nested data, and defensive handling of optional fields. You'll apply all these patterns extensively throughout this chapter.
API Access: You'll need free API keys for NewsAPI (500 requests/day) and The Guardian (5,000 requests/day). HackerNews requires no authentication. Section 2 provides registration URLs and setup instructions.