Security Review Process

EveryAction uses a tiered risk management structure to determine the level of security review an application must meet before it can be used in production. Tier 1 is the lowest and will allow developers to send data into EA8, but not export, while Tier 4 is the highest.

New developers will be given Tier 1 sandbox access by default.

It is important that developers fully spec out the endpoints they plan to utilize prior to beginning integration so they can apply for access at the appropriate tier.

For example, building an integration to add a supporter to an organization’s CRM might use POST /people/findOrCreate, a Tier 1 feature, but if the application also was going to update scores with PATCH /scoreUpdates, a Tier 4 feature, the developer would be required to meet Tier 4 requirements.

An overview of endpoints and their associated security tier is below. If you are unsure what endpoints will be most useful to your integration, please don’t hesitate to reach out. We also anticipate that many developers will iterate on their integrations over the course of time, so you should expect to be asked for additional information as you increase in tiers and as we add new features that may be useful to your integration.

Review Process

There are two security reviews that integrations will generally have to go through. The first is a Platform Review by EveryAction (using the tiered model below) and the second is a Tool review by the client's team.

The Platform Review is a onetime process and will "stay" with the vendor across their work with EveryAction clients. This review is designed as a baseline audit of integration security best practices - no vendor trying to certifying at an appropriate tier should 'fail' this process.

In addition, many clients have their own vendor review. While some clients (especially those not working on voter file data) will accept the Platform Review in place of another formal process, larger clients will ask vendors to fill out an secondary review specific to their security guidelines.

Both review can often be completed in parallel, especially if you have a client who's looking to use this integration already in mind.

See below for a diagram outlining the step by step process a successful vendor will complete to have their integration live in production.

General Tiers

*note: this set of Email endpoints retrieve meta data about email messages sent via TGE, not actual email addresses. You can get a contact's email address using GET/people/{vanid} or via an Export Job.

Export Jobs

Export Jobs are the specific data points that are being pulled in an export. If you imagine a CSV, people records would be the rows while the fields in an export job are the columns. Use of the Export Jobs endpoint is generally not limited, but the fields included are tiered based off the security requirements mentioned above. As a reminder, voter data is a provided to EveryAction by the client or a separate vendor and as such is considered at a higher level of security. Developers with questions on this should feel free to reach out and we are happy to help connect you with the correct point of contact within a specific client organization.

🚧

Note on exporting addresses

Please note that the Address and ZipCode export fields only support US addresses while FullAddress and ZipOrPostal are present in databases that have international addresses enabled. The former should be used with My Voters while the latter is most often used with My Campaign.

Export Job Examples

For ease of use we will often issue developers a numeric export job type (for example Type ID 123) which will pull the same set of export fields every time it is used. VANID is unique to a contact record and often can be utilized in replace of PII. Some examples of frequently used export jobs are listed below.