Record Response Helper Version 2

This document describes the record response helper endpoint as implemented by the Action Network.

The record response helper allows you to create or update a person record and mark that person as having filled out a survey at the same time (as well as tag that person).

This saves API calls. POSTing a new response without the helper would mean you need a link to the person you want to associate the response with, which would entail either an oData search to look up the existing person or a POST using the person_signup_helper to add the person first. The record response helper allows you to post a person's data along with a response, and the helper will automatically create or deduplicate the person and then create a response for them on the specified survey, all in one API call.

People are matched and deduplicated by phone number and email address, both of which can be attached to an activist record. People are required to have either an email address or a phone number. If a person is posted without an email address, a record with only phone number will be created and vice versa. If adding or changing a phone number results in more than one activist having the same number for your group, one of two things will happen. If both activists have email addresses, the phone number will be removed from the old activist and added to the new activist. If one of the activists is a mobile-only record, then the records will be merged. More on deduplicating here.

If the email or phone number posted corresponds with a person already in the system, we update their record instead of creating a new person. If the person is new to your email list, they will be subscribed to the email list associated with your API key. (In networks, subscribed statuses will travel up the network. Unsubscribed statuses will not).The only valid status is subscribed, no other status fields are valid at this endpoint.

People's mobile subscription status works differently than email subscription status. If they are new to your mobile list, by default they will be added as unsubscribed, unless you pass subscribed If they are an existing person already in your group, the person's mobile subscription status will not be changed, unless you pass subscribed in the mobile status field. (In networks, if this group does has the 'mobile status goes up the network' setting checked, a mobile subscribed status will travel up the network where an unsubscribed will not.) No other status fields are valid on this endpoint.

Items in the optional add_tags and remove_tags array are matched to existing tags associated with the list matching your API key by name. If a matching tag is found, that tag will be added or removed from the person's record. If not, the tag will be ignored. The operation to add tags will always run before the operation to remove tags.

An optional triggers object can be added as well, indicating an autoresponse email should be sent back to the activist, which typically thanks them for taking action. Autoresponse emails are only sent from actions created with our user interface, and will respect the autoresponse settings in that action's Responses tab on its manage page. For example, if you're POSTing to a survey that has the autoresponse email turned on and you include the autoresponse trigger, the activist will get an autoresponse email as normal, thanking them for taking action. If you're POSTing to a survey with the autoresponse turned off, they won't get that email.

Background processing is available on this operation via the background_request=true URL argument. You can learn more about background processing here.

Finally, you can POST to this helper without an API key. This is useful to enable a javascript implementation, say the use of a custom form that you create, without leaking your API key to browsers. If you use unauthenticated or blind POST without an API key, the response will be essentially no information, to avoid leaking any personal data over the API without an API key present. You will receive a success status code and an empty JSON response if successful, or an error status code and an error message if not. See the blind post tutorial for an example.

Sections:

• Endpoint
• Field names and descriptions
• Related resources
• Scenario: Creating a new response (POST)

Endpoint

Endpoint:

https://actionnetwork.org/api/v2/surveys/[survey_id]/responses

The record response helper lives at the endpoint relating to the collection of responses on a specific survey.

Back To Top ↑

Field names and descriptions

Record Response Helper fields:

Referrer Data fields:

Triggers fields:

Autoresponse fields:

Back To Top ↑

Related resources

• Responses
• Surveys
• People

Back To Top ↑

Scenario: Creating a new response (POST)

If you post with an inline person hash instead of with a link to a person object as described here, we will create or update the matching person and associate them with a new response on the specified survey, all in one API call.

An email address or phone number is the only required field, though others can be POSTed.

Tags can also be added to a person's record when POSTing using the helper by including the optional tags array. Items in the array are matched to existing tags associated with the list matching your API key by name. If a matching tag is found, that tag will be added to the person's record. If not, the tag will be ignored.

And an optional triggers object can be added, indicating an autoresponse email should be sent back to the activist, which typically thanks them for taking action. Autoresponse emails are only sent from actions created with our user interface, and will respect the action's response options settings.

Finally, you can POST to this helper without an API key. This is useful to enable a javascript implementation, say the use of a custom form that you create, without leaking your API key to browsers. See the blind post tutorial for an example.

Here is an example of posting a response with person data inlined to the special record_response_helper link on the response collection, along with tags and an autoresponse:

Request

						
POST https://actionnetwork.org/api/v2/surveys/9f837109-710d-442f-8a99-857a21f36d25/responses/

Header:
Content-Type: application/json
OSDI-API-Token: your_api_key_here


{
  "person" : {
    "family_name" : "Smith",
    "given_name" : "John",
    "postal_addresses" : [ { "postal_code" : "20009" }],
    "email_addresses" : [ { "address" : "jsmith@mail.com" }],
    "phone_numbers": [ {"number": "2021234444" }]
  },
  "add_tags": [
    "volunteer",
    "member"
  ],
  "remove_tags": [
    "inactive"
  ],
  "triggers": {
    "autoresponse": {
      "enabled": true
    }
  }
} 
					

Response

						
200 OK

Content-Type: application/hal+json
Cache-Control: max-age=0, private, must-revalidate


{
  "identifiers": [
    "action_network:c7630707-34f2-48ee-a6c2-46214b94663a"
  ],
  "created_date": "2014-03-26T18:14:04Z",
  "modified_date": "2014-03-26T18:14:04Z",
  "action_network:person_id": "17be9a36-bb9a-4f68-94a8-40523b9dab27",
  "action_network:survey_id": "9f837109-710d-442f-8a99-857a21f36d25",
  "_links": {
    "self": {
      "href": "https://actionnetwork.org/api/v2/surveys/9f837109-710d-442f-8a99-857a21f36d25/responses/c7630707-34f2-48ee-a6c2-46214b94663a"
    },
    "action_network:survey": {
      "href": "https://actionnetwork.org/api/v2/surveys/9f837109-710d-442f-8a99-857a21f36d25"
    },
    "osdi:person": {
      "href": "https://actionnetwork.org/api/v2/people/17be9a36-bb9a-4f68-94a8-40523b9dab27"
    },
    "curies": [
      {
        "name": "osdi",
        "href": "https://actionnetwork.org/docs/v2/{rel}",
        "templated": true
      },
      {
        "name": "action_network",
        "href": "https://actionnetwork.org/docs/v2/{rel}",
        "templated": true
      }
    ]
  }
}
					

In the above example, a new person was created and their response added to the survey at the same time. The tags 'volunteer' and 'member' were added to that person's record as well. They received an autoresponse email from the action, according to its response option settings in the user interface. We deduplicate people added this way by email address and phone number, so if the email or phone number posted corresponded with a person already in the system, we would update their record instead of creating a new person. The required fields for person remain the same -- email address or phone number -- and any posts missing that information will fail.

If the person is new, they will be subscribed to the email list associated with your API key. If not, their subscription status (subscribed, unsubscribed, etc...) will not be changed unless you pass subscribed in the status field, as described in the people documentation. In that case, they will be subscribed to the email list, even if they were previously unsubscribed. No other status fields are valid on this endpoint.

New people are not automatically subscribed to the mobile list. They will not be subscribed to the mobile list unless you pass subscribed in the phone status field, as described in the people documentation.

Of course you can POST a response with more fields such as address lines for your inline person data or custom fields if you'd like, but they are not required. And you can omit your API key, in which case the response will a success status code and an empty JSON object if successful, or an error code and message if not.

Back To Top ↑