Using the Sync API

SyncApi.md

API

This describes the resources that make up the official Revere Sync V2. If you have any problems or requests please contact [Sam Robertson](mailto: srobertson@revolutionmessaging.com).

• Overview
• Current Version
• Schema
• Integration Fields
• Base Endpoint
• Constituents

Overview

Sync works to keep data in multiple places and attepmts to update changes with user interaction. Sync is setup internally at Revolution Messaging and a revere team member can assist you in obtaining an access token as well as setup integrations that you may require. Sync uses triggers to activate data forwarding, these are activated by the tag field. With your access token a tag will be provided that you can use to activate the correct data forwarding services as setup with your Sync integration.

Current Version

All requests must be made through the API and include the accept header to get the correct version of the API. The exception is the constituent route. This does not require an accept header and always defaults to V1 of the Sync V2 API for backwards compatibility reasons. This is the route that will be most used by our clients and by developers.

Accept: application/vnd.sync.v1+json

Schema

All API access is over HTTPS, and accessed from the sync.revmsg.net domain. All data is sent and received as JSON unless otherwise noted. Sent with Content-Type as JSON.

Content-Type: application/json

Integration Fields

Per integration Sync interacts with there a some fields that can and cannot be used. As each service Sync ineracts with has their limitations. It will send all data if available.

--

Revere Mobile

Sync will forward metadata to revere mobile and will activate a Mobile Flow. A Mobile Flow will then activate and add tags as setup by the Mobile Flow options if desired. This integration requires a Mobile Flow to be entered in Sync.

• name
• firstname
• lastname
• address
• address_two
• city
• email
• state
• zipcode

Action Kit

Sync will forward this data to Action Kit. If a user exists it will attempt an update based on the msisdn or the email. Prefering the msisdn as a unique person it will search by msisdn first and create/update the below information.

• name
• firstname
• lastname
• address
• address_two
• city
• email
• state
• zipcode
• msisdn

Blue State Digital

Sync uses the BSD pages API to post information to BSD. These fields are supported by Sync. The update/create procedure follows BSD's implementation that can be found here.

• email
• firstname
• lastname
• phone
• zip
• city
• state

NGP/ EveryAction 7

An NGP / EveryAction 7 integration is powered by the Sign Up and Petition pages NGP and EveryAction 7 can generate. The NGP / EveryAction 7 integration requires an API Url and an API Key to function.

• firstname
• lastname
• address
• address_two
• city
• email
• work email
• state
• zip code
• mobile phone (msisdn)
• home phone
• work phone
• metadata
• emailOptInStatus => [“I” for In, “O” for Out, sets to “O” by default]

VAN / EveryAction 8

The Sync integration with VAN / EveryAction 8 is the same for both services. Just as the NGP / EveryAction 7 is as well. The VAN / EveryAction 8 is much more simple, this will post Persons known as People in VAN / EveryAction 8. It requires a VAN API Key that is for US customers for VAN as well as an API User. There is also the option to use Online Actions for VAN / EveryAction 8. This follows the same params as the NGP / EveryAction 7 integration above.

• firstname
• lastname
• address
• address_two
• city
• email
• state
• zip code
• msisdn
• home phone
• work phone
• work address
• work address_two
• work_city
• work_zipcode
• work email
• mail address
• mail address
• mail address_two
• mail city
• mail zip code
• Metadata
  • preferredPhone => [work_phone, home_phone, msisdn]
  • preferredEmail => [email, work_email]
  • phoneOptInStatus => [“I” for In, “O” for Out, sets to “O” by default]
  • emailOptInStatus => [“I” for In, “O” for Out, sets to “O” by default]

--

Base Endpoint

Production

https://sync.revmsg.net

--

Constituents

Constituents are the main actor in Sync and actions by triggers are preformed on them. It is possible to create constituents with GET and PUT requests but this method is highly discouraged and only exists for backwards compatibility with V1. All constituents should be created using the POST method.

Create a constituent

Parameters

Name	Type	Required	Description
access_token	String	True	Access Token Hash

POST /constituent/:access_token
Content-Type: application/json

Request

At least one paramater is required to post data. Below are the allowed fields for a constituent. The tag parameter is required to activate the triggers which will forward information to Sync's integrations.

Name	Type	Required	Description
name	String	False	Full name, will be created from firstname and lastname automatically if possible.
firstname	String	False	First Name of Constituent
lastname	String	False	Last Name of Constituent
address	String	False	Primary Street Address
address_two	String	False	Secondary Street Address
city	String	False	City of Constituent
state	String	False	Two Char String ( IE: WA )
zipcode	String	False	Five Digit Zip Code and four seperated by -. 98036 or 98036-1513 are OK.
email	String	False	Email of Constituent
work_email	String	False	Work Email of Constituent
phone	String	False	Phone of Constituent, will populate msisdn when phone provided.
msisdn	String	False	Mobile Phone number of Constituent, gets populated by phone if only phone is provided.
work_phone	String	False	Work Phone number of Constituent
home_phone	String	False	Home Phone number of Constituent
employer	String	False	Employer of Constituent
work_address	String	False	Work address of Constituent.
work_address_two	String	False	Work address, second line of Constituent
work_city	String	False	Work city of Constituent.
work_state	String	False	Work State, TWO Char String (IE: WA).
work_zipcode	String	False	Work Zip Code, a five digit zip code and four seperated by -. 98036 or 98036-1513 are OK.
mail_address	String	False	Mail address of Constituent.
mail_address_two	String	False	Mail address, second line of Constituent
mail_city	String	False	Mail city of Constituent.
mail_state	String	False	Mail State, TWO Char String (IE: WA).
mail_zipcode	String	False	Mail Zip Code, a five digit zip code and four seperated by -. 98036 or 98036-1513 are OK.
vote_address	String	False	Voter address of Constituent.
vote_address_two	String	False	Voter address, second line of Constituent
vote_city	String	False	Voter city of Constituent.
vote_state	String	False	Voter State, TWO Char String (IE: WA).
vote_zipcode	String	False	Voter Zip Code, a five digit zip code and four seperated by -. 98036 or 98036-1513 are OK.
metadata	Object	False	Metadata object (see table), IE: source:string for an ActionKit integration
tags	String	False	Can be one String or an Array of Strings

MetaData Field Object	Type	Required	Description
source	string	False	A string, such as facebook, twitter, EveryActionForm etc.
preferredPhone	string	False	Must be msisdn, work_phone, or home_phone and field must be present.
preferredEmail	string	False	Must be email or work_email and field must be present.
phoneOptInStatus	string	False	Must be I for in or O for out. Default is O.
emailOptInStatus	string	False	Must be I for in or O for out. Default is O

Example Request

JSON Request Body

{
	"name":"Steve Bob",
	"firstname":"Steve",
	"lastname":"Bob",
	"address":"555 Fake St.",
	"address_two":"APT 24",
	"city":"Seattle",
	"state":"WA",
	"zipcode":"98045",
	"email":"steve@steve.com",
	"home_phone":"1-555-555-5555",
	"msisdn":"1-555-555-5555",
	"employer":"Steve's Company",
	"metadata": {
		"source":"facebook",
		"emailOptInStatus":"I"
	},
	"tags":"amazingpeople2016"
}

Response

{
  "error":false,
  "message":"Contact accepted.",
  "id":"57d723cbd9dc8cdc5ad00191"
}