Object Reference

This document contains a description of the objects available via the LeadConduit API.

Flow

The Flow is the primary unit of work in LeadConduit. When a lead is submitted to LeadConduit, the flow ID is specified and the lead is processed according to the instructions in that flow.

Property Description Type
id The ID of the flow which uniquely identifies it BSON ID
name The name of this flow that is displayed throughout LeadConduit's UI String
enabled Turns a flow on and off. Leads cannot be submitted to a disabled flow Boolean
fields The IDs of the fields collected in this flow Array of Field IDs
sources The sources which can submit leads to this flow Array of Sources
steps The steps to be processed for each submitted lead Array of Steps
caps The limits of leads to accept from this flow Array of Caps
acceptance_criteria The definition of the kinds of leads to accept to this flow Acceptance Criteria
pricing The pricing configuration for all sources in this flow Pricing

^ back to top

Source

When a lead is submitted to a flow, the source's entity ID is specified. LeadConduit uses the configured integration for that source, checks the lead against the configured acceptance criteria for that source, and attributes the lead to the source entity.

Property Description Type
id ID for this source in this flow Short ID
integration The integration to be used for this source in this flow Integration
entity The entity to which submitted leads are attributed Entity
acceptance_criteria The definition of the kinds of leads to accept from this source Acceptance Criteria
feedback The configuration for sending feedback to the source Feedback
credential_id The ID of a credential that the integration should use to authenticate BSON ID
caps The limits of leads to accept from this source Array of Caps
pricing The pricing configuration for this source (takes precedence over flow pricing) Pricing

^ back to top

Step

When a lead is submitted, the flow's list of steps is processed one after another in order. As each step is processed an Event is created which summarizes what happened during processing. There are two kinds of steps.

Filter Step

A filter step is used to stop processing a lead from advancing to the next flow step. This is conceptually similar to an email inbox filter. If the lead matches the rules then the flow is stopped, which effectively filters out the lead. When a filter step stops the flow, the source receives an immediate response and no further steps are processed.

Property Description Type
id ID for this step Short ID
type The type of the step (always filter) String
enabled Whether this step should be run when processing a lead or not Boolean
description A brief description of what this filter does String
rule_set The flow stops when the rules match the lead Rule Set
outcome When the flow stops, success, failure or error is returned to the source that submitted the lead String
reason When the outcome is failure or error, this is the reason to provide to the source Template

When a filter step processes a lead, a Filter Event is created.

^ back to top

Recipient Step

A recipient step is used to invoke an integration to an external server, system, or platform.

Property Description Type
id ID for this step Short ID
type The type of the step (always recipient) String
enabled Whether this step should be run when processing a lead or not Boolean
entity The entity representing the recipient of leads for this step Recipient
rule_set If the rules fail, the step generates a "skip" event Rule Set
integration The integration to be used for this step Integration
feedback The configuration for receiving feedback from the recipient Feedback
caps The limits of leads to send to this recipient Array of Caps
pricing The pricing configuration for this recipient Pricing

^ back to top

Rule Set

A rule set is a collection of rules to evaluate. The op property determines whether all rules must pass (and) or just one of them must pass (or) in order for the rule set to be considered passing.

Property Description Type
op The required operator. Rules are combined using and or or. String
rules The required rules to be evaluated. Rule sets may also be specified as array elements in order to achieve nesting. Array of Rules and/or Rule Sets

^ back to top

Rule

A rule is the construct used in a Rule Set to reason about lead data. When a rule is evaluated, the lhv is examined using the op. For example, a rule might have lhv: 'lead.first_name', op: 'must not be blank'. When evaluated, this rule passes if the lead.first_name variable contains a value and the value is not an empty string.

Property Description Type
id ID for this rule Short ID
lhv The required left-hand value to be evaluated Variable or Template
op The required operator Operator
rhv The right-hand value to be evaluated. Not allowed when using a unary op. Template

^ back to top

Operator

Rule operators are responsible for performing the core logic of a Rule. Every rule must have an operator. There are two kinds of operators. The below tables describe the available operators and what Types they can be used with.

Binary Operators

Binary operators compare the lhv and the rhv of a Rule.

Operator Description Types
is equal to Is the lhv exactly equal to the lhv? string (case sensitive), number, range
is not equal to Does the lhv contain a value different from the rhv? string (case sensitive), number, range
is less than Is the lhv numerically less than the rhv? number, range
is less than or equal to Is the lhv numerically less than or equal to the rhv? number, range
is greater than Is the lhv numerically greater than than the rhv? number, range
is greater than or equal to Is the lhv numerically greater than or equal to the rhv? number, range
is between The lhv is between the range's min and max (inclusive) range
is not between The lhv is not between the range's min and max (exclusive) range
is included in The lhv is included in the Array of values provided in the rhv string, number, boolean
is not included in The lhv is not included in the Array of values provided in the rhv string, number, boolean
includes The Array of values provided in the lhv contains the rhv Array of strings, numbers, booleans
does not include The Array of values provided in the lhv does not contain the rhv Array of strings, numbers, booleans

^ back to top

Unary Operators

Unary operators evaluate only the lhv of a Rule. For rules that use a unary operator, an rhv cannot be provided.

Operator Description Types
is blank Is the lhv missing or empty? all
is not blank Does the lhv contain a value? all
is true Does the lhv evaluate to true? boolean
is false Does the lhv evaluate to false? boolean
format is valid The lhv was successfully interpreted as a value of its specified type. all
format is invalid The lhv could not be interpreted as a value of its specified type. all

^ back to top

Acceptance Criteria

Acceptance criteria specifies the kinds of leads that a source or sources must provide in a flow. Acceptance criteria can be configured at both a flow level and a source level. When a source submits a lead, the flow-level acceptance criteria's rule set is evaluated first, then any source-level acceptance criteria. If the rule sets pass, then the lead is allowed to progress on in the flow. But if either rule set fails, then the source is immediately given a response and no further processing takes place in the flow for that lead.

Property Description Type
rule_set This rule set must pass in order for a lead to be accepted Rule Set
outcome When the rule set fails, success, failure or error is returned to the source that submitted the lead String
reason When the outcome is failure, this is the reason to provide to the source Template

^ back to top

Integration

Property Description Type
enabled A flag that turns the integration on and off (only supported for feedback) Boolean
module_id A pointer to the integration code to use for this integration Module ID
mappings The mappings to apply to lead data when interacting with this integration Array of Mappings

^ back to top

Mapping

A mapping is a rule-based translation that can be applied when a lead is submitted from a source or applied when submitting a lead to a recipient.

Property Description Type
id ID for this mapping Short ID
property The name of the variable to set String
value The value to set Template
rule_set Only apply the mapping if this rule set passes Rule Set

^ back to top

Feedback

Feedback specifies the configuration for receiving and sending feedback about a lead. When receiving feedback from a recipient, the rule_set must pass. If it does not, a "failure" Feedback Received Event event is created. When sending feedback to a source, the rule_set must pass. If it does not, a "skip" Feedback Sent Event event is created.

Property Description Type
rule_set If the rules fail the feedback is not performed Rule Set
integration The integration to be used for the feedback Integration

^ back to top

Cap

A cap allows limiting the number of leads sent to a flow. If a lead is successful, it will be counted against the maximum configured leads. If configured, the rule set will be evaluated to determine whether a lead will be counted against the cap.

Cap Configuration

The cap configuration is defined in a flow on a source, recipient step, or directly on the flow itself. The configuration controls the behavior of the cap. By setting the maximum and the duration. The counter for a cap is kept as a standalone record which shares cap's ID.

Property Description Type
id ID of this cap BSON ID
type The type of this cap: volume (LeadConduit may eventually support different types of caps) String
name The human-readable name of the cap String
maximum The number of successful leads that will be accepted Integer
duration The number duration_units the cap persists for Integer
duration_units The unit of time the cap persists for: minute, hour, day, week, or month String
rule_set This rule set must pass in order for the lead to count against the cap Rule Set
caps Nested caps evaluated if rules for the parent cap pass Array of Caps
time_zone The time zone in which cap resets String
reason When the cap is met this is the reason (default: 'Cap reached') Template
created_at Read-only time the cap was created Timestamp

Cap Counter

A cap counter keeps track of the number of leads counted against the cap. The counter has the same ID as the cap configuration saved with the flow. Most of the properties of the cap configuration are available on the cap counter, as a convenience.

Property Description Type
id ID of this counter (matches the ID of the corresponding cap configuration) BSON ID
name The human-readable name of the cap String
count The number of successful leads during the current interval Integer
failed_count The number of leads that failed because the cap was reached during the current interval Integer
flow_id The ID of the associated flow BSON ID
source_id The ID of the Source if the cap is defined on a source BSON ID
step_id The ID of the step in the flow if the cap is defined on a step Short ID
type The type of this cap: volume (LeadConduit may eventually support different types of caps) String
maximum The number of successful leads that will be accepted Integer
duration The number duration_units for which the cap persists Integer
duration_units The unit of time for which the cap persists: minute, hour, day, week, or month String
rule_set This rule set must pass in order for the lead to count against the cap Rule Set
counters A list of counters, one for each child cap Array of Cap counters
time_zone The time zone in which the cap resets String
expires_at Read-only time the cap interval ends Timestamp
started_at Read-only time the cap interval started Timestamp

^ back to top

Pricing

A pricing configuration determines the value of the purchase_price property on source events or the value of the sale_price property on recipient events. Consequently, it also determines the cost and revenue properties on source and recipient events. These properties can be reported on via the statistics API and the reporting API. If no pricing is configured, then the purchase_price and sale_price properties will be set to 0.

Pricing can be set on sources in a flow, the flow itself, or on any recipient step in a flow.

A pricing is primarily an array of prices. Each price is evaluated and the last price for which all rules match will determine the amount used for the purchase_price or sale_price. If no prices match for a particular lead, the price properties will be set to 0.

If you wish the source or recipient to specify the price, then override property on the pricing must be set to true. When override: true, the price properties on the associated event will be set to whatever amount is provided by the source or recipient. The prices array must be empty, null, or undefined if override: true.

Property Description Type
prices The list of prices to evaluate for each lead Array of Prices
override Allows a source or a recipient to specify the price rather than relying on prices Boolean

Price

A price determines the purchase_price or sale_price for a lead. If all rules in the rule_set pass, then the appropriate price property will be set equal to the amount. When more than one price is specified, the last matching price will be used to set the price property on the event.

Property Description Type
id ID of this counter (matches the ID of the corresponding cap configuration) Short ID
amount The price of the lead in USD Float
rule_set The rule set which must pass in order for this price to be considered Rule Set

^ back to top

Event

An event tracks what happened with a lead at a particular step in a flow. An event is a self-contained snapshot of the state of the lead at the time the lead visited the step. It contains a full copy of all lead data, along with all data that was appended before that step. Every event contains the below properties.

Property Description Type
id The ID of the event which uniquely identifies it BSON ID
type The type of the event: filter or recipient String
outcome The outcome of the event String
reason The reason for the outcome String
vars All data available at the time the step was invoked Variables
ms The number of milliseconds that elapsed while processing the step Integer
overhead_ms The number of milliseconds of overhead that LeadConduit added while processing the step Integer
total_ms The number of milliseconds that elapsed since the lead was submitted Integer
handler_version The semantic version of the lead handler Semantic Version
start_timestamp The number of milliseconds elapsed since epoch at the start of the step processing Integer
end_timestamp The number of milliseconds elapsed since epoch at the end of the step processing Integer
expires_at The time this event will be automatically deleted from LeadConduit (events are retained for 90 days) Timestamp
version The schema version of the event Semantic Version

Filter Event

A filter event is created when a lead is processed by a filter step. A filter event records the below properties in addition to the Event properties shown above.

Property Description Type
description The description configured on the filter step when String
rule_set The rule set configured on the filter step when the lead was processed Rule Set

The possible outcome values of a filter event are:

The reason value of a filter event is set by evaluating the reason template of the filter step.

Recipient Event

A recipient event is created when a lead is processed by a recipient step. A recipient event records the below properties in addition to the Event properties shown above.

Property Description Type
module_id The integration module ID configured on the recipient step Module ID
rule_set The rule set configured on the recipient step when the lead was processed Rule Set
mappings The mappings configured on the recipient step Array of Mappings
package_version The version of the integration package Semantic Version
key The property name on the event where appended data is stored String
<key> The appended data Object
transactions A list of HTTP transactions that occured while processing the lead Array of HTTP Transactions
wait_ms The number of milliseconds LeadConduit to get the response from the recipient's server Integer

When a lead is processed by a recipient step, the associated integration is resolved using the module_id and invoked. The integration contacts the recipient's server and determines the outcome and reason for the transaction. Different integrations determine outcome in different ways, so it's important to know what success or failure mean for a particular integration.

The possible outcome values of a recipient event are:

^ back to top

Source Event

The source event is created after all steps have been processed. It represents the outcome of lead processing from the perspective of the lead source. A source event records the below properties in addition to the Event properties shown above.

Property Description Type
module_id The integration module ID configured on the source Module ID
acceptance_criteria The acceptance criteria configured on the source when the lead was processed Acceptance Criteria
step_count The number of steps processed for this lead Integer (>= 0 and <= total number of steps)
package_version The version of the integration package Semantic Version
handler_version The semantic version of the lead handler Semantic Version
appended All appended data Object
request The inbound HTTP request HTTP Request
response The inbound HTTP response HTTP Response

The possible outcome values of a recipient event are:

success — The source was notified in the response that the lead was accepted failure — The source was notified in the response that the lead was rejected error — The source was notified in the response that an error occured while processing the lead

^ back to top

Feedback Received Event

A feedback-received event is created when lead feedback is provided by a recipient. The feedback configuration must be provided on the recipient step. A feedback-received event records the below properties in addition to the Event properties shown above.

When feedback is received, only the following lead variables are copied from the original recipient event, when available: lead.id, lead.first_name, lead.last_name, lead.phone_1, and lead.reference.

When feedback is configured to be sent to the source, the feedback-received event's outcome and reason are copied from the feedback-sent event. In other words, if the source refuses the feedback, the recipient will receive a "failure" outcome in response to the feedback call.

Property Description Type
recipient_event_id The ID of the recipient event used to provide the feedback BSON ID
step_id The ID flow step that originally sent the lead to the recipient Short ID
feedback A copy of the feedback configuration Feedback

^ back to top

Feedback Sent Event

A feedback-sent event is created when lead feedback is sent to a source. The feedback configuration must be provided on the source in the flow. A feedback-sent event records the below properties in addition to the Recipient Event properties shown above.

When feedback is sent, the following lead variables are copied from the original recipient event, when available: lead.id, lead.first_name, lead.last_name, lead.phone_1, and lead.reference.

Property Description Type
recipient_event_id The ID of the recipient event used to provide the feedback BSON ID
step_id The ID flow step that originally sent the lead to the recipient Short ID
feedback A copy of the feedback configuration Feedback

^ back to top

Event Statistics

Event statistics report aggregate counts of events broken out by outcome (success, failure, or error). Event statistics can be grouped by arbitrary lead data and the resulting "row" represents events counted by the combination of the specified lead data fields. Statistics can also be bucketized into intervals (minutely, hourly, daily, weekly, monthly, yearly) and doing so adds the start and end properties to the results and the counts represent the events that occurred during the time frame defined by the start and end timestamps.

Property Description Type
total Sum of success, failure, and error counts Integer
success The number of events that finished with a success outcome Integer
failure The number of events that finished with a failure outcome Integer
error The number of events that finished with a error outcome Integer
start The start time of the specified interval Timestamp
end The end time of the specified interval Timestamp
<property> One or more properties as specified by the group_by option String

^ back to top

Event Statistics Filter Rule

When querying an API that uses analytics, a filter limits the kind of events analyzed. If an event matches the filter, it's included in the analytics results. Otherwise, it's not.

Property Description
rhv The name of the property to filter (e.g. vars.lead.email.domain)
op The operator to use on the property name (see below table)
lhv The value to compare to the property specified by the property_name

Event Statistics Filter Rule Operator

Operator Description Types
is equal to Equal to – Note that if your property’s value is an array, "is equal to" can be used to filter for values inside that array. For example, eq: 5 will match a value of [5, 6, 7]. String, Number, Boolean
is not equal to Not equal to String, Number, Boolean
is less than Less than Number
is less than or equal Less than or equal to Number
is greater than Greater than Number
is greater than or equal Greater than or equal to Number
is blank Whether or not a specific property exists on an event record. The value passed in must be either true or false. String, Number, Boolean
is included in Whether or not the property value is in a given set of values. The value passed in must be an array of values. Example: [1,2,4,5]. String, Number, Boolean
includes Whether or not the string property value contains the given sequence of characters. Array, String
does not include Whether or not the string property value does not contain the given sequence of characters. Array, String

Not all filter operators make sense for different property data types, so only certain operators are valid for each.

Note: For contains and "includes" and "does not include" operators, the property must exist in order for the event to pass the filter. If the property does not exist, then the event will not pass the rule and will not be returned as part of the result set.

^ back to top

Entity

An entity is used to track lead flow. Each entity can be a source or a recipient or both. Entities can be used in multiple flows. When an entity is a source, it can be added to a flow as a source and when it is a recipient, it can be added to a flow as a recipient.

Property Description Type
id The ID of the entity which uniquely identifies it BSON ID
name The name of the entity which is displayed throughout LeadConduit's UI String
source The type of source: null, form, seller, or other String
recipient The type of source: null, buyer, crm, analytics, enhancement, esp, or other String
logo_url The logo for this entity String (HTTP URL)
field_suffix The suffix required for all custom fields 3-5 character alphanumeric String
standard Read-only flag indicating whether this is a built-in entity Boolean
account Read-only flag indicating whether this entity represents another LeadConduit account holder Boolean
module_ids Array of integration module IDs that are supported by this entity Array of Module IDs
deprecated The flag indicating that this entity should no longer be used Boolean
see The alternative entity ID to be used instead of this deprecated entity BSON ID
created_at The time this entity was created Timestamp
updated_at The time this entity was last modified Timestamp

^ back to top

Field

A field represents a piece of data collected about a lead. When a field is referenced by ID from a flow's fields property, that piece of data will be captured when submitted. LeadConduit provides a large catalog of built-in fields, so there should rarely be a need to create a custom field. Custom fields are those where the standard property is false.

Property Description Type
id The required alphanumeric identifier of the field Field ID
type The required data type of this field Type
name The required name of this flow that is displayed throughout LeadConduit's UI String
description The textual description of the purpose of this field String
standard Read-only flag indicating whether this is a built-in LeadConduit field Boolean
deprecated The flag indicating that this field should no longer be used Boolean
see The alternative field ID to be used instead of this deprecated field Field ID
created_at Read-only time the field was created Timestamp
updated_at Read-only time the field was last updated Timestamp

^ back to top

Standard Fields

The catalog of standard fields that are built in to LeadConduit are available at docs.leadconduit.com.

Field ID

A field is uniquely identified by its id property. No two fields may have the same ID. A field ID is a String that may include lowercase letters, numbers, the period character, and the underscore character (/a-z0-9_./). Field IDs are meant to be human readable (i.e. first_name, last_name, email).

When the "Generic POST" inbound or outbound integration is used, the field ID serves as the HTTP parameter name that LeadConduit uses.

^ back to top

Changelog

A changelog represents a creation, update, or deletion of a model such as Flow, Entity, or Field. Every change made will log the exact difference between the previous revision and the current one, as well as what user was logged in and what account the change was made on. Contained within the changelog is the full revision of the model changed at the state after the change was applied, as well as the differences between the previous revision and current revision.

Property Description Type
id The ID of the changelog which uniquely identifies it BSON ID
type The type of model changes were performed on: flow, entity, field String
action Action performed: create, update, delete String
user User information; only present if User was logged in when changes were made User
current_revision Latest revision of model; format will be one of: Flow, Entity, Field Object
delta_from_last_revision An object representing the difference between the previous revision and the latest revision of the model Delta Format
changes An object representing the normalization of the delta object Array of Changes
created_at Time the changelog was created Timestamp

^ back to top

User

Simple object with information to identify the user who made the changes. This will only be present if a User was logged in when the changes were made. Any changes made with an account API Key will be anonymous, and this user object will not be available.

Property Description Type
id The ID of the user which uniquely identifies it BSON ID
first_name The first name of the user who made the change String
last_name The last name of the user who made the change String
email The email of the user who made the change String

^ back to top

Change

The change object is a normalization of the delta object, and is contained within an array to easily list all of the changes made.

Property Description Type
target The target of the change, which could be any property within the model being changed String
action The action that was performed on the changed object: added,removed,changed,moved String
delta_path The path that represents where the change is located within the delta object String
current The state of the target object after the change was made Change State
previous The state of the target object before the change was made Change State

^ back to top

Change State

Property Description Type
index The index of the object that was changed Number
value The value of the object that was changed Object

^ back to top

Credential

A credential is used by LeadConduit's rich integrations to authenticate with third party platforms. Once a credential is established, it can be used across flows. A credential ID can be specified on a source in a flow or in recipient step's integration mappings. All credentials support the below properties. Additional properties that are not shown below may also be stored.

Property Description Type
id The ID of the credential which uniquely identifies it BSON ID
type The type of model changes were performed on: user, token, oauth String
package The name of the LeadConduit integration package to which this credential belongs String
name Friendly name for this credential String
created_at Time the credential was created Timestamp
updated_at Time the credential was last updated Timestamp

^ back to top

User Credential

In addition to the Credential properties above, a user credential has the below:

Property Description Type
username The user name with which to authenticate String
password The password with which to authenticate String

^ back to top

Token Credential

In addition to the Credential properties above, a token credential has the below:

Property Description Type
token The token with which to authenticate String

^ back to top

OAuth2 Credential

In addition to the Credential properties above, an OAuth2 credential has the below:

Property Description Type
access_token The token with which to authenticate String
refresh_token The token with which to request a new access token String

^ back to top

Lead Search Result

A lead search result is returned when searching for a lead. The response from the /search/leads endpoint contains the total number of matching leads and an array of hits, where each hit is a lead search result. Each lead search result contains the following properties:

Property Description Type
address_1 street address String
city city String
email email address String
first_name first name String
flow_id unique ID of the flow String
flow_name name of the flow String
last_name last name String
lead_id unique ID of the lead String
phone_1 phone number String
phone_2 alternate phone number String
postal_code zipcode String
reference vendor specific String
source_id unique ID of the source String
source_name name of the source String
state state abbreviation String
submission_timestamp time the lead was submitted Timestamp
highlight object containing properties for each matching field. The values of the properties are arrays of the matching text, wrapped in <em> tags Object
latest_event last event recorded for this lead Event

^ back to top

Variable

A variable is a key/value pair that is available to filters, rule sets and mappings and in templates at run time while processing a lead.

Every lead is born with a standard set of variables, and additional variables are added at run-time as leads are processed by each step in the flow. The full set of variables are stored on every event (in the vars property) generated during lead processing.

Variables are stored on events as nested objects and are referenced at runtime using dot-notation. There are several top-level variable prefixes that logically group variables.

Variable Prefix Description
lead. Lead data submitted by the source
source. Metadata about the source
flow. Metadata about the flow
recipient. Metadata about the recipient (available on recipient steps and in recipient events only)
submission. Metadata about the lead submission itself
feedback. Metadata about lead feedback (only present during feedback processing)

^ back to top

Lead Variable

A variable prefixed with lead. is a lead variable. Lead variables are created when a lead is submitted by a source to a flow. These variables typically contain data that was collected from the consumer on a web form.

Each variable name corresponds to a field ID. If the source submits a piece of data and the matching field ID has not been added to the flow, then a variable with that data will not be created. If the source needs to submit data using a parameter that does not have a matching field name, then a mapping must be added to map the source's parameter to the field name. For example, if a source submits fname=Joe then a mapping must be added in order to create the lead.first_name variable with the value "Joe".

For a list of all possible lead variables that are available "out of the box" in LeadConduit, simply prepend lead. to any of the standard field IDs.

^ back to top

Source Variable

A variable prefixed with source. is metadata about the source that submitted the lead. Source variables are created automatically when a lead is submitted.

Variable Description Type
source.id The unique ID of the source BSON ID
source.name The name of the source String

^ back to top

Flow Variable

A variable prefixed with flow. is metadata about the flow that handled the lead. Flow variables are created automatically when a lead is submitted.

Variable Description Type
flow.id The unique ID of the flow BSON ID
flow.name The name of the flow String

^ back to top

Recipient Variable

A variable prefixed with recipient. is metadata about the recipient that received the lead. Recipient variables are created automatically when a lead is submitted to a recipient. These variables are only present on recipient events.

Variable Description Type
recipient.id The unique ID of the recipient BSON ID
recipient.name The name of the recipient String

^ back to top

Submission Variable

A variable prefixed with submission. is metadata about an actual lead submission. Submission variables are created automatically when a lead is submitted.

Variable Description Type
submission.timestamp The time the lead was submitted Time

^ back to top

Feedback Variable

A variable prefixed with feedback. is metadata about lead feedback. Feedback variables are created automatically when a feedback provided.

Variable Description Type
feedback.timestamp The time the feedback was provided Time
feedback.type The type of feedback provided (return or conversion) String
feedback.reason The underlying reason why feedback was provided String

^ back to top

Variable Usage

When a variable is populated during lead processing, LeadConduit records some metadata about the variable including when it was used, which flow it was used in, and some examples of the variable value.

A variables usage has the following properties:

Property Description Type
name The time the feedback was provided Time
label The human-readable variable name String
type The data type of the variable value Type
description The description of the variable value String
last_used_at The last time the variable was populated Timestamp
entity_id Identifies the entity of the recipient step if the variable is appended data BSON ID
module_id Identifies the integration specified on the recipient step if variable is appended data Module ID
flow_ids Identifies all the flows which populated the variable Array of BSON IDs
examples Up to 10 example variable values Array

^ back to top

Type

A type is a string that represents the kind of data in a Field or Variable. LeadConduit supports the following types.

Boolean Type

Boolean fields and variables are declared as type boolean.

^ back to top

Credential Type

Credential fields and variables are declared as type credential.

^ back to top

Date Type

Date fields and variables are declared as type date.

^ back to top

Email Type

Email fields and variables are declared as type email.

^ back to top

Number Type

Number fields and variables are declared as type number.

^ back to top

Phone Type

Phone fields and variables are declared as type phone.

^ back to top

Postal Code Type

Postal Code fields and variables are declared as type postal_code.

^ back to top

Range Type

Range fields and variables are declared as type range.

^ back to top

SSN Type

US Social Security Number fields and variables are declared as type ssn.

^ back to top

String Type

String fields and variables are declared as type string.

^ back to top

Time Type

Time fields and variables are declared as type time.

^ back to top

Integration Package

An integration package contains one or more integrations.

Property Description Type
id The unique ID of the package (i.e. leadconduit-salesforce) String
name The name of the package (i.e. Salesforce) String
description The human readable description of the integration package String
version The semantic version of the package Semantic Version
ui Does this package support a rich user experience? Boolean
images Does this package contain images such as special logos? Boolean
integrations An array of all integration metadata available in this package Array of Integrations Metadata

^ back to top

Integration Metadata

An integration is a pointer to the code that executes an individual inbound or outbound integration. An integration is contained in an integration package. For example, the Salesforce package contains multiple integrations including: "Add Lead" and "Create Contact".

Property Description Type
id The unique identifier of the integration (i.e. leadconduit-salesforce.outbound.create_lead) Module ID
name The name of the integration inside the integration module String
direction This integration either handles inbound or outbound submissions String
type The type of the integration: enhancement, marketplace enhancement, or delivery (available on outbound integrations only) String or null
description The human readable description of the integration, describing what it does String
entity_id The unique ID of the standard entity representing this integration (available on enhancement and marketplace enhancement integrations only) BSON ID
feedback Does this integration support feedback? Boolean
median_wait_ms The median number of milliseconds LeadConduit waits from a response from this integration, system-wide Integer
pricing The pricing for this integration Integration Pricing
request_variables The fields provided by an inbound integration, or fields provided to an outbound integration Array of Request Variables
response_varialbes The fields returned by an inbound integration, or fields appended by an outbound integration Array of Response Variables

^ back to top

Integration Pricing

Integration pricing defines how much it costs to use an integration. There are several types of pricing: flat, tiered, volume, and agreement. Each type differs slightly in terms of the model. All types of pricing share similar properties:

Property Description Type
type The structure of the pricing model: flat, tiered, volume, and agreement String
unit The units of the item being charged String
transaction Is this pricing just the standard LeadConduit transaction pricing? Boolean

^ back to top

Flat Pricing

An integration with flat pricing cost the same no matter how many units you use.

Property Description Type
unit_price The price in USD for each unit used in your account Decimal

^ back to top

Tiered Pricing

An integration with tiered pricing charges a different amount for each unit depending on the unit_price for the total quantity used. For example, the first 1000 units cost $0.01, the next 1000 units cost $0.005, the next 1000 units cost $0.0025, etc.

Property Description Type
tiers An array of tiers, each having start_qty, end_qty, and unit_price Tier

^ back to top

Volume Pricing

An integration with volume pricing charges one unit_price for all units used in the entire billing period. That unit price is based on the total quantity of units used in the billing period. For example, if you use 1000 units then the price is of all units is $0.10. If you use 2000 units, then the price of all units drops to $0.05, and so on.

Property Description Type
tiers An array of tiers, each having start_qty, end_qty, and unit_price Tier

Agreement Pricing

If you have a special pricing agreement with ActiveProspect, your pricing will be returned as agreement pricing. Typically pricing agreements have a base subscription cost that includes a certain amount of volume. Any volume over that amount is billed like flat pricing. Pricing agreements are not supported on self-service (non-contracted) accounts.

^ back to top

Integration Module

An integration module is a pointer to the code that executes an individual inbound or outbound integration. A module is contained in an integration package. For example, the Salesforce integration package contains two individual integration modules: Add Lead and Create Contact.

Property Description Type
id The unique identifier of the integration module Module ID
type The type of the integration module: inbound or outbound String
name The name of the integration inside the integration module String
package Metadata about the package containing the integration Integration Module Package
path The path of this integration inside the integration package String
request_variables The fields provided by an inbound integration, or fields provided to an outbound integration Array of Request Variables
response_varialbes The fields returned by an inbound integration, or fields appended by an outbound integration Array of Response Variables

^ back to top

Integration Module Package

An integration package contains multiple integration modules.

Property Description Type
description The human readable description of the integration package String
name The name of the package (i.e. Salesforce) String
paths An array of pointers to each integration inside this package Array of Strings
ui Whether this integration supports a rich user experience Boolean
repo_url The URL to the source code repository for this module's package URL
version The semantic version of the package containing this integration Semantic Version

^ back to top

Integration Variable

Variables are used when communicating with integrations.

Outbound integrations have a list of request variables. These are the variables provided to the integration for the purpose of executing an outbound integration as part of a recipient step. Outbound integrations also provide a list of response variables. These are the variables the integration provides after the integration is executed. They are appended to the full list of lead variables available while handling a lead.

Inbound integrations have a list of request variables. These are the variables that are populated by the inbound integration when a lead is submitted to LeadConduit. These variables are mapped and the results are stored in the lead variables for use while processing the lead. The response variables for an inbound integration represent the data returned back to the submitting party by the inbound integration after lead processing has completed.

Property Description Type
name The identifier of the variable (i.e. lead.first_name) String
description The human readable description of the variable String
required Whether or not the variable is required by the integration Boolean
type The type of data contained in the variable Type

^ back to top

HTTP Transaction

A HTTP request and response.

Property Description Type
request The HTTP request that was sent HTTP Request
response The HTTP response that was received HTTP Response
ms The number of milliseconds that elapsed between sending request and receiving the response Integer

^ back to top

HTTP Request

Property Description Type
method HTTP request method (i.e. GET, POST, PUT, DELETE, etc) String
uri The full URI (i.e. http://whatever.com/some/path?param=value) String
version The HTTP version used (only 1.1 is currently supported) String
headers The headers sent on the request Object
body The request body String
timestamp The number of milliseconds elapsed since epoch immediately prior to sending the request Integer

^ back to top

HTTP Response

Property Description Type
status HTTP status code (i.e. 200, 201, 404, 500, etc) Integer
status_text The textual representation of the status (i.e. OK, Created, Not Found, Internal Server Error, etc) String
version The HTTP version used (only 1.1 is currently supported) String
headers The headers received in the response Object
body The response body String
timestamp The number of milliseconds elapsed since epoch immediately after reading the response body Integer

^ back to top

Module ID

A module ID is a pointer to a function inside an integration's NPM module. It is the dot delimited concatenation of two different parts:

Example: the module ID for the TrustedForm claim integration is leadconduit-trustedform.outbound.claim. This ID is based on the package name defined in the TrustedForm package.json file and the path to the claim module inside the integration.

^ back to top

BSON ID

A 24 character hexidecimal string identifier. An identifier is guaranteed to be unique across all objects of the same type.

^ back to top

Short ID

A 6 character string identifier, consisting of lower case letters, upper case letters, and numbers 0-9. Not globally unique.

^ back to top

Timestamp

In LeadConduit, timestamps on objects are always provided in ISO8601 format in the UTC timezone. The format is YYYY-MM-DDTHH:MM:ss.SSSZ. For example 2015-07-28T19:14:44.033Z.

^ back to top

Template

LeadConduit supports combining, formatting, hashing, and performing math on values using template markup. Templating in LeadConduit is based on the popular Handlebars semantic templating library. A template is a string which contains any number of variable placeholders.

^ back to top

Template Variable

Variable placeholders in templates start and end with two curly-brace characters: {{ lead.first_name }}. Multiple placeholders can be combined in a single template: {{ lead.first_name }} {{ lead.last_name }}. The universe of possible variables available to a template depends on the fields defined in your flow and the steps you've added to your flow.

^ back to top

Variable Formatting

LeadConduit has a built-in helper for formatting numbers and dates. Formatting a value is done with the format helper. If the value is a date field, then you may use date formatting options with the helper. If it's a number field, then you may use the number formatting options with the helper.

^ back to top

Date Variable Formatting

To format a date, use the format helper: {{ format lead.dob format="YYYY-MM-DD" }} results in '2015-06-24'. The format option is a string which defines the format of the date. This format can be any combination of any of the below tokens. To escape characters in format strings, you can wrap the characters in square brackets: {{ format lead.dob format="[It's] MMMM Do" }} results in "It's October 12th".

^ back to top

Date Format Tokens

Token Output
Month M 1 2 ... 11 12
Mo 1st 2nd ... 11th 12th
MM 01 02 ... 11 12
MMM Jan Feb ... Nov Dec
MMMM January February ... November December
Quarter Q 1 2 3 4
Qo 1st 2nd 3rd 4th
Day of Month D 1 2 ... 30 31
Do 1st 2nd ... 30th 31st
DD 01 02 ... 30 31
Day of Year DDD 1 2 ... 364 365
DDDo 1st 2nd ... 364th 365th
DDDD 001 002 ... 364 365
Day of Week d 0 1 ... 5 6
do 0th 1st ... 5th 6th
dd Su Mo ... Fr Sa
ddd Sun Mon ... Fri Sat
dddd Sunday Monday ... Friday Saturday
Day of Week (Locale) e 0 1 ... 5 6
Day of Week (ISO) E 1 2 ... 6 7
Week of Year w 1 2 ... 52 53
wo 1st 2nd ... 52nd 53rd
ww 01 02 ... 52 53
Week of Year (ISO) W 1 2 ... 52 53
Wo 1st 2nd ... 52nd 53rd
WW 01 02 ... 52 53
Year YY 70 71 ... 29 30
YYYY 1970 1971 ... 2029 2030
Y 1970 1971 ... 9999 +10000 +10001 Note: This complies with the ISO 8601 standard for dates past the year 9999
Week Year gg 70 71 ... 29 30
gggg 1970 1971 ... 2029 2030
Week Year (ISO) GG 70 71 ... 29 30
GGGG 1970 1971 ... 2029 2030
AM/PM A AM PM
a am pm
Hour H 0 1 ... 22 23
HH 00 01 ... 22 23
h 1 2 ... 11 12
hh 01 02 ... 11 12
k 1 2 ... 23 24
kk 01 02 ... 23 24
Minute m 0 1 ... 58 59
mm 00 01 ... 58 59
Second s 0 1 ... 58 59
ss 00 01 ... 58 59
Fractional Second S 0 1 ... 8 9
SS 00 01 ... 98 99
SSS 000 001 ... 998 999
SSSS ... SSSSSSSSS 000[0..] 001[0..] ... 998[0..] 999[0..]
Time Zone z or zz EST CST ... MST PST (requires use of the timezone option)
Z -07:00 -06:00 ... +06:00 +07:00
ZZ -0700 -0600 ... +0600 +0700
Unix Timestamp X 1360013296
Unix Millisecond Timestamp x 1360013296123

^ back to top

Localized Date Formats

Because preferred formatting differs based on locale, there are a few tokens that can be used to format a moment based on its locale.

There are upper and lower case variations on the same formats. The lowercase version is intended to be the shortened version of its uppercase counterpart.

To change the locale, use the locale options: {{ format date format="LLL" locale="fr" }} results in "24 juin 2015 17:24".

Format string Output
Time LT 8:30 PM
Time with seconds LTS 8:30:25 PM
Month numeral, day of month, year L 09/04/1986
l 9/4/1986
Month name, day of month, year LL September 4, 1986
ll Sep 4, 1986
Month name, day of month, year, time LLL September 4, 1986 8:30 PM
lll Sep 4, 1986 8:30 PM
Month name, day of month, day of week, year, time LLLL Thursday, September 4, 1986 8:30 PM
llll Thu, Sep 4, 1986 8:30 PM

^ back to top

Number Variable Formatting

To format a number, use the format helper: {{ format lead.mortgage.first_mortgage_balance format="$0,0.00"}} results in '$45,302.00'. The format option is a string which defines the format of the number. See the table of examples below:

Number Format String
10000 '0,0.0000' 10,000.0000
10000.23 '0,0' 10,000
10000.23 '+0,0' +10,000
-10000 '0,0.0' -10,000.0
10000.1234 '0.000' 10000.123
100.1234 '00000' 00100
1000.1234 '000000,0' 001,000
10 '000.00' 010.00
10000.1234 '0[.]00000' 10000.12340
-10000 '(0,0.0000)' (10,000.0000)
-0.23 '.00' -.23
-0.23 '(.00)' (.23)
0.23 '0.00000' 0.23000
0.23 '0.0[0000]' 0.23
1230974 '0.0a' 1.2m
1460 '0 a' 1 k
-104000 '0a' -104k
1 '0o' 1st
100 '0o' 100th
1000.234 '$0,0.00' $1,000.23
1000.2 '0,0[.]00 $' 1,000.20 $
1001 '$ 0,0[.]00' $ 1,001
-1000.234 '($0,0)' ($1,000)
-1000.234 '$0.00' -$1000.23
1230974 '($ 0.00 a)' $ 1.23 m

Use the locale option to format the number to a particular locale: {{ format lead.mortgage.first_mortgage_balance locale="fr" format="$0,0.00" }} results in '€45 302.00'.

^ back to top

Variable Math

To perform math operations, use the math helper: {{ math "1 + 1" }} results in 2. Of course, variables can also be used: {{ math "1 + lead.random_number" }} might result in 32 depending on the value of lead.random_number. The math expression accepts a pretty basic grammar. Operators have the normal precedence:

Operator Associativity Description
(...) None Grouping
f(), x.y Left Function call, property access
! Left Factorial
^ Right Exponentiation
+, -, not, sqrt, etc. Right Unary prefix operators (see below for the full list)
*, /, % Left Multiplication, division, remainder
+, -, || Left Addition, subtraction, concatenation
==, !=, >=, <=, >, <, in Left Equals, not equals, etc. "in" means "is the left operand included in the right array operand?" (disabled by default)
and Left Logical AND
or Left Logical OR
x ? y : z Right Ternary conditional (if x then y else z)

There are also several pre-defined functions:

Function Description
sin(x) Sine of x (x is in radians)
cos(x) Cosine of x (x is in radians)
tan(x) Tangent of x (x is… well, you know)
asin(x) Arc sine of x (in radians)
acos(x) Arc cosine of x (in radians)
atan(x) Arc tangent of x (in radians)
sqrt(x) Square root of x. Result is NaN (Not a Number) if x is negative.
log(x) Natural logarithm of x (not base-10). It’s log instead of ln because that’s what JavaScript calls it.
abs(x) Absolute value (magnitude) of x
ceil(x) Ceiling of x — the smallest integer that’s >= x.
floor(x) Floor of x — the largest integer that’s <= x
round(x) X, rounded to the nearest integer, using "gradeschool rounding"
roundTo(x, n) Rounds x to n places after the decimal point
exp(x) ex (exponential/antilogarithm function with base e)
random(n) Get a random number in the range [0, n). If n is zero, or not provided, it defaults to 1.
fac(n) n! (factorial of n: “n * (n-1) * (n-2) * … * 2 * 1″)
min(a,b,...) Get the smallest (“minimum”) number in the list
max(a,b,...) Get the largest (“maximum”) number in the list
pyt(a, b) Pythagorean function, i.e. the c in “c2 = a2 + b2“
pow(x, y) xy. This is exactly the same as “x^y”. It’s just provided since it’s in the Math object from JavaScript
atan2(y, x) arc tangent of x/y. i.e. the angle between (0, 0) and (x, y) in radians
if(c, a, b) Function form of c ? a : b

Example

To calculate the loan-to-value ratio, given a mortgage loan amount and the value of the home: {{ math "(lead.mortgage.loan.amount / lead.mortgage.new_property_value) * 100" }}%. Note that this example expresses the LTV as a percentage, first by calculating the percentage and then by appending the % character outside the variable placeholder. This could instead be handled using formatting.

^ back to top

Variable Math Formatting

The math helper supports the same options as the format helper for numbers: format and locale. For example, to calculate the loan-to-value ratio and format it as a percentage: {{ math "lead.mortgage.loan.amount / lead.mortgage.new_property_value" format="0.[00]%" }}. This would return the LTV percentage with up to 2 decimal points (i.e. 72.93%) as a string value.

^ back to top

Variable Hashing

LeadConduit supports a wide variety of hashing functions that can be applied to variables in a template. The helper name determines the hashing algorithm. For example, to use MD5 to hash the email address use: {{ md5 lead.email }}.

All of the following hashing algorithms are supported:

Multiple values can be hashed together: {{ md5 lead.email lead.phone_1 }}. This can be used to salt the hash also: {{ md5 lead.email "this is my salt" }}. The salt option can also be used. This is the equivalent of the last example: {{ md5 lead.email salt="this is my salt" }}.

Hashing supports multiple encodings using the encoding option: {{ md5 lead.email encoding="base64" }} results in something like "tkK0IXs0sejTvZFfxlxEUg==". The following encodings are supported:

^ back to top