api-docs.pulsehealth.tech Open in urlscan Pro
44.213.246.33  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Public


Documentation Settings

ENVIRONMENT
PEC Production

LAYOUT
Double Column

LANGUAGE
cURL - cURL



Pulse Engagement Cloud API
Introduction
Pulse Engagement Cloud API Documentation
Getting Started
Registration Forms (best practice)
Working with List endpoints
Account Request
Actions
Action Codes
Campaigns
Contacts
Contact Emails
Contact Locations
Contact Phones
Creatives
Forms
From Lines
NPI Match
Segments
Segment Contacts
Sources
Conditional Emails


PULSE ENGAGEMENT CLOUD API


PULSE ENGAGEMENT CLOUD API DOCUMENTATION

The Pulse Engagement Cloud API is meticulously designed following the principles
of Representational State Transfer (REST). This architectural style defines our
API's foundation, where resource-oriented URLs serve as pathways to interact
with the system. Requests are expected to be in JSON-encoded format, and
responses are delivered in the same JSON encoding. Standard HTTP response codes
ensure clarity in API interactions.

For your development convenience and the preservation of live/production data
integrity, we offer the provision of a staging environment. This environment is
isolated from your live/production data and is intended for testing purposes.
Should you find value in this environment, don't hesitate to reach out to your
dedicated Pulse Health account manager. They will be more than willing to set up
this environment for you.

Understanding that each account has unique needs, the Pulse Engagement Cloud API
adapts to cater to those needs. Custom fields and integrations, among other
functionalities, are tailored to align with your account's requirements.
Depending on the customization needed, this may affect requirements and
responses for different APIs.


GETTING STARTED

To start sending requests to the Pulse Engagement Cloud API, you will need to
get the values for your account's Account ID and API Token.

> To get the Account ID and API Token, please ask your Pulse Health account
> manager.


API LIMITATIONS

Please note, we currently only support API request from secure backend servers
and prevent front end browsers/clients from connecting to the API.


AUTHORIZATION

To authorize a request for the Pulse Engagement Cloud API, you must set request
headers for the Account ID and API Token.

Plain Text


Authorization: API-TOKEN YOUR_API_TOKEN_HERE
X-Account: YOUR_ACCOUNT_ID_HERE

Note: Make sure to include API-TOKEN as part of the authorization header.

Plain Text


Example:
Authorization: API-TOKEN xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
X-Account: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

If using Postman, you can use the {{ apiToken }} and {{ accountId }} variables
in the environment to set the values. For more information about environments,
see the Postman documentation.


REGISTRATION FORMS (BEST PRACTICE)

There are two options for how to handle sending data for registration/sign-up
forms.


OPTION 1 (RECOMMENDED): USE THE FORM SUBMISSION API

As of March 6th, 2024, we have created new standard for processing forms
containing contact data.

We recommend using this new feature due to ease of use, and additional features
such as configuration of post-submission actions (e.g., creating a form
submission action).

Please view the Form Submission API documentation here


OPTION 2 (LEGACY): USE THE CONTACT API

The Contact API enpoints are a powerful tool that allows you to efficiently
manage contact information. This guide will walk you through the process of
performing an API lookup to search for a contact's email, creating a new contact
if the email address doesn't exist, and updating the contact if the email
address already exists.


PREREQUISITES

Before you begin, make sure you have the following:

   
 * Access to the Contact Management API (including the necessary Account ID and
   API Token).
   
 * A programming environment that supports making HTTP requests. We do not
   support CORS so the requests should be sent from a backend server.
   


API LOOKUP AND CONTACT HANDLING

Perform an API Lookup

To search for a contact's email address using the API, you'll typically need to
make a GET request to the appropriate endpoint, passing the email address as a
parameter. The API will respond with the contact's information if the email
exists or with an appropriate response if the email is not found.
Example Request:
[GET] /contacts/search?groups[]=contact_display_email&simpleSearch={EMAIL
ADDRESS}

Create a New Contact

If the API lookup doesn't return any results, you can assume that the email
address doesn't exist in the database. In this case, you can proceed to create a
new contact by making a POST request to the endpoint designed for contact
creation. Please note, Source is required. Also, the custom fields section in
the example below is only an example. Your account manager can guide you with
what specific values you can pass for your specific account.

Example Request:
[POST] /contacts

Example Payload:

View More
json


{
  "salutation": "Dr", // Optional
  "firstName": "Example", // Optional
  "middleName": "", // Optional
  "lastName": "Example", // Optional
  "credentials": "MD", // Optional
  "gender": "M", // Optional
  "npi": "1234567890", // Optional - This stands for National Provider Identifier. This is a unique identifier given to doctors. Leave blank for patient data.
  "specialty": "Oncology", // Optional
  "contactType": "HCP", // Optional - for patient data please set as "Patient"/“Caregiver”/etc.
  "source": 1, // Required - This will be a static number that references data you send. We can provide this value to you. Values might differ between staging and production environments.
  "emails": [
    {
      "emailAddress": "example@email.com", // Required if saving email address
      "isSubscribed": true, // Should be true if the patient is signed up for Email Messages
    }
  ],
  "locations": [
    {
      "company": "The Night's Watch", // Optional
      "addressLine1": "1 Wall St.", // Required only if storing Address Line 2, otherwise optional
      "addressLine2": "Suite 100", // Optional
      "city": "New York", // Required only if storing Address Line 1, otherwise optional
      "state": "NY", // Required only if storing City and/or Address Line 1, otherwise optional
      "postalCode": "10001", // Required only if storing Address Line 1, otherwise optional
      "country": "USA" // Optional
    }
  ],
  "phones": [
    {
      "phone": "5165551212", // Required if saving phone number
      "isPhoneSubscribed": true, // Should be true if the contact is signed up for Phone Calls
      "isSmsSubscribed": true, // Should be true if the contact is signed up for Text Messages
      "isFax": false // Optional
    }
  ],
  "customFields": {
    "sampleNumericField": 12345, // This is just an example
    "sampleBoolenField": true, // This is just an example
    "sampleStringField": "USA" // This is just an example
  },
  "isTest": false  // Should be false for real contacts and true test contacts. 
                   // If set to true, Test contacts statistics will not calculated in reports and hidden from standard search.
}

Update an Existing Contact

If the API lookup returns a valid contact's information, you can proceed to
update the contact. To do this, make a PUT request to the endpoint for updating
contacts, providing the contact's ID along with the updated information.

Example Request:
[PUT] /contacts/{id}

Example Payload:

View More
json


{
  "salutation": "Dr", // Optional
  "firstName": "John", // Optional
  "lastName": "Snow", // Optional
  "specialty": "Oncology", // Optional
  "emails": [
    {
      "id": 1001, // The ID of the email address belonging to the contact
      "emailAddress": "example@email.com", // Required if saving email address
      "isSubscribed": true, // Should be true if the contact is signed up for Email Messages
    }
  ]
}


WORKING WITH LIST ENDPOINTS

This API will contain endpoints to retrieve listings of different resources.
Most endpoints will contain common query parameters that will help with
specifying which data fields to return and sorting. If the endpoint does not
allow this feature, the documentation for that endpoint will clearly state this.

Please view the resource's main folder documentation for a list of fields that
can be used for field restriction and sorting.


FIELD RESTRICTION

The data in the list endpoint response can be restricted to only return specific
fields. To do this, you must set a query parameter for the fields[] array.

If no fields[] array exists in the request, all data is returned. This query
parameter is useful in cases where you don't want or can't see certain data
points.

Another use case is to optimize the response in cases of large data sets.


SORTING

You can sort the results by fields based on ascending or descending order. To do
this, you must set a query parameter for the sort[] array.

As you can tell, since the parameter is an array, you can sort by multiple
fields in the same request. The order of the sorting is dependent on the order
of the values in the sort[] array.

The value must be formatted as {field}:{order}. The field and order are
separated by a colon (:). For example, if you wanted to sort by the contact's
created date to see the newest contacts first, the value would be
createdAt:DESC. If you wanted to sort by the contact's last name in alphabetical
order, the value would be lastName:ASC.

AUTHORIZATIONAPI Key
Key

Authorization

Value

<value>