American Energy Alliance Scorecard

Photo by Matthew Henry on Unsplash

Role: Contributing Developer

Collaboration: Marketing, Client Leadership, Project / account management

Key contributions:

  • Inherited a custom WordPress plugin originally written against ProPublica’s Congress API (later sunset); I re-architected and rewrote the integration for api.congress.gov as upstream capabilities and payloads changed.

  • Because the new API wasn’t a drop-in replacement, I added chamber-specific ingestion (House and Senate) to recover committee coverage, including workflows that ingested raw XML, parsed/normalized it, and piped results into PHP structures for database persistence.

  • Persisted votes, members, and committees as discrete database records (your one-row-per-entity model) so the public experience could read merged local data and stay within reasonable API usage.

  • The admin model already included Votes and Bills custom post types (I didn’t create the original CPTs), but I extended and reworked both heavily as the APIs shifted: Votes for the editorial/scoring layer around what the organization treats as meaningful votes, and Bills for the legislative items AEA wanted members to be scored against (the “what should they vote on” side of the product).

  • Embedded DataTables in plugin page templates with AJAX backed by the WordPress database (not per-interaction live API calls).

  • Provided a manual admin refresh path for pulling current API data (preferred over crons).

  • Public reference: americanenergyalliance.org/american-energy-scorecard (may evolve post-handoff).

- Updated: May 1st, 2026 -

The American Energy Scorecard educates lawmakers about the most important energy votes of the year and empowers the American people to hold their elected officials accountable for the decisions they make in Washington.

The Scorecard backend lived in a custom WordPress plugin that originally integrated ProPublica’s Congress API (now sunset). I inherited that codebase and did a substantial rewrite for api.congress.gov so ingestion, normalization, and persistence matched new endpoints, new constraints, and new gaps compared with the older integration.

The rewrite wasn’t only “swap the base URL.” The new API didn’t offer the same breadth in practice, so I implemented additional chamber-specific requests (House vs Senate) to rebuild committee coverage the UI depended on. Some sources like chamber votes and bills weren’t JSON-first: I handled raw XML, parsed it into structured data, and moved it through PHP so it could be merged with the rest of the pipeline and written into the WordPress database as individual rows for votes, members, and committees.

On the WordPress admin side, the product already relied on Key Votes and Bills CPTs to connect organizational intent to legislative reality (I didn’t author the original CPT scaffolding). As the data model changed, I updated and expanded both: Key Votes for the editorial layer around what counts for the Scorecard, and Bills for the items AEA expected members to take positions on, so the site could track “what we asked for” alongside “what happened on the floor.”

Public-facing exploration ran through DataTables inside plugin templates, fed by AJAX reading from the local database. Updates were intentionally manual in admin (fetch current data on demand) rather than cron-driven, matching how the team wanted to operate the integration day to day.