By Param Siddharth

Roadmap:

• What is civictech?
• Comparing Google Civic API or Cicero
• What was the app structure we’re modifying from
• Why we chose Cicero

Open source is the perfect home for civictech..what is it?

Over the years, an interesting ecosystem is emerging within open source projects - civictech. Whether its your local C4A or universities looking to engage in their communities..the spirit of open source and the space of technology bettering our communal infrastructure are deeply in alignment.

An example I was hands on via the MLH Fellows in the ProgramEquity experience was the Amplify App which is powering the streamlining of civic engagement data so advocacy groups can accelerate their social impact.

Like any civictech project, a large element of data gathering is connected to mapping jurisdictions to the correct stakeholders - the feedback loop with public sector organizations. Many APIs offer various degrees of

General comparison of Civic Data APIs

Amplify App Use Case

Amplify has a CRUD App structure using multiple APIs. All APIs are part of a codespaces dev container so maintainers are able to contribute directly via a web editor.

When considering our decision matrix:

• Difficulty of API Configuration was less of a concern as we can bypass the need of local setup
• Focus was on speed of data callback as the app is used in events and other dynamic instances
• Scope became availability of localized data as our partners continue to focus on civic engagement within municipalities and cities

Choosing Cicero creates a consistent and more local experience

Its less costly to build with all open source tools - however, we appreciated Cicero having a credits program for nonprofits which allowed us to overcome cost and tap into the following benefits

• Continuity of maintenance: a completeness of each representative profile allows for a more dependable user experience
• Had pictures in their datasets
• Scope: local enough upto school districts

Fetching the data from the Google Civic API in Amplify used to look like:

• We are only passing the zip code and the filter as the query parameters in addition to the key.
• We can’t sort or limit the results.
• We plan to skip the president and vice president from the results. Here, we skip the first two in case of unfiltered results, assuming they will be the president and vice president.

Updated approach using Cicero’s API:

• We are using qs for the query parameters. It is a non-standard approach to have more power over customized query parameters. That’s how we’re able to pass arrays into the query parameters.
• We can pass multiple district types as a filter. In the Google Civic API we could only pass one district type in the filter.

For all the responses that we get, we fit them into a certain specific object schema that the front-end expects us the return.

Here’s now we did while using the Civic API:

• There’s no guarantee we will have the social media information.
• The e-mail and photo are absent for most cases.
• There’s no unique identifier.

And here’s how we do it in using the Cicero API:

• Photos are consistently available.
• We have a unique identifier for each representative (helpful for caching).
• The address is being returned in well-formatted sections from the Cicero API.
• Social media information is more readily available.

The limitations of the Google Civic API and the lack of consistent information is what led us to move to using the Cicero API for fetching data. We eventually plan to harness the capabilities of the response of the Cicero API for:

• Implementing a caching strategy to avoid spending too many credits.
• Style the images in the perfect fashion using the co-ordinate and dimension information we receive from the API response to configure individual CSS parameters.