> ## Documentation Index > Fetch the complete documentation index at: https://developers.activeprospect.com/llms.txt > Use this file to discover all available pages before exploring further. # Fetch a ping limit counter > Get a counter for a single ping limit. ## OpenAPI ````yaml /api-reference/leadconduit_api.json get /ping_limits/{id} openapi: 3.1.0 info: title: LeadConduit API version: 1.0.1 termsOfService: https://activeprospect.com/terms-of-service/ contact: name: ActiveProspect Support Team email: support@activeprospect.com url: https://support.activeprospect.com description: | # About This documentation is a technical manual for the LeadConduit API. It is primarily intended to be read by software developers who want to integrate another system with LeadConduit. The API is RESTful and speaks JSON over HTTPS. In general, anything that can be accomplished by pointing and clicking in the LeadConduit user interface can also be done using the API. ## Conventions This documentation provides examples that show how to interact with the API. Examples are shown in monospaced blocks like the one shown below: ``` Examples are presented in blocks like this one ``` You may also see monospaced font inline `like this`. This text represents a literal value or expression to be used with the API. ## Questions If you have a question, or spot an error in the documentation, or just generally need to speak with someone about the API, email [support@activeprospect.com](mailto:support@activeprospect.com). servers: - url: https://app.leadconduit.com description: The base URL for production. security: - APIKey: [] tags: - name: Destinations description: > Destinations are similar to a recipient step in a flow; they represent an external system which receives lead data at the end of a flow. Data is sent to a Destination if all prior steps have completed successfully, and are skipped if an error occurs in a prior step. Destinations are configured once and then globally available within all of an account's flows. Destinations must be configured within the [LeadConduit app](https://app.leadconduit.com), and cannot be configured directly via the API. However, once a destination is configured, it can be queried via the API. Configured destinations can also be added to flows via the API. - name: Flows description: > A flow defines how leads are processed. A flow can include a range of actions, including validation, normalization, and distribution, that are applied to leads as they move through the flow. Each step in the flow is represented by a "node," which can perform a specific action or set of actions on the lead. For example, a node might validate the lead's phone number or email address, normalize the lead's data, or distribute the lead to a specific destination based on predefined rules. Flows can be customized to meet the specific needs of your business, and LeadConduit offers a range of pre-built templates and tools to help you create a flow that fits your unique requirements. Overall, flows are a powerful feature of the LeadConduit platform that enable you to streamline lead processing, automate lead distribution, and improve lead quality, all while maximizing your ROI. Free accounts do not have access to Flows (https://app.leadconduit.com/flows) and will receive a 401 (Unauthorized) error when trying to access it - name: Fields description: >- 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. Free accounts do not have access to Fields (https://app.leadconduit.com/fields) and will receive a 401 (Unauthorized) error when trying to access it - name: Changelogs - name: Events - name: Leads description: >- Free accounts do not have access to Leads (https://app.leadconduit.com/leads) and will receive a 401 (Unauthorized) error when trying to access it - name: Entities description: > 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. - name: Firehose description: >- # Firehose Multi-Service Configuration ## Overview Each flow is separately configured to use the firehose. This API allows firehose configuration to be tested before it is set on a flow. The Firehose feature supports multiple cloud storage services for event data export. This document describes the configuration options for both AWS S3 and Azure Blob Storage services. ## Configuration Structure ### Legacy Configuration (Backward Compatible) For existing flows, the legacy configuration continues to work: ```json { "firehose": { "enabled": true, "credential_id": "507f1f77bcf86cd799439011", "bucket": "my-s3-bucket", "prefix": "events/production" } } ``` ### New Service-Based Configuration The new service-based configuration allows multiple cloud storage providers: ```json { "firehose": { "enabled": true, "services": { "aws": { "enabled": true, "credential_id": "507f1f77bcf86cd799439011", "bucket": "my-s3-bucket", "prefix": "events/aws" }, "azure": { "enabled": true, "credential_id": "507f1f77bcf86cd799439012", "bucket": "my-azure-container", "prefix": "events/azure" } } } } ``` ## Credential Validation ### AWS S3 Validation The `/firehose` endpoint validates AWS credentials by: 1. Creating a test file with unique name: `leadconduit_verification_[flow_id_]YYYYMMDDHHMMSSMS.txt` 2. Uploading it to the specified bucket (with optional prefix) when `verification_file=true` (default) 3. Alternatively, validating bucket access without creating file when `verification_file=false` 4. Returning the S3 response with ETag or validation confirmation **Example Requests:** *Basic validation (creates file):* ```bash curl -X GET "https://app.leadconduit.com/firehose?service=aws&access_key_id=AKIA...&secret_access_key=wJal...&bucket=my-bucket&prefix=test" ``` *With flow ID (includes flow identifier in filename):* ```bash curl -X GET "https://app.leadconduit.com/firehose?service=aws&access_key_id=AKIA...&secret_access_key=wJal...&bucket=my-bucket&flow_id=507f1f77bcf86cd799439011" ``` *Validation only (no file created):* ```bash curl -X GET "https://app.leadconduit.com/firehose?service=aws&access_key_id=AKIA...&secret_access_key=wJal...&bucket=my-bucket&verification_file=false" ``` **Example Responses:** *File created:* ```json { "validated": true, "verification_file": true } ``` *Validation only:* ```json { "validated": true, "verification_file": false } ``` ### Azure Blob Storage Validation The `/firehose` endpoint validates Azure credentials by: 1. Creating a BlobServiceClient from the connection string 2. Checking if the specified container exists and is accessible 3. Optionally creating verification file based on `verification_file` parameter 4. Returning container validation information **Example Request:** ```bash curl -X GET "https://app.leadconduit.com/firehose?service=azure&connection_string=DefaultEndpointsProtocol=https;AccountName=test;AccountKey=key;EndpointSuffix=core.windows.net&bucket=my-container" ``` **Example Responses:** *With verification file:* ```json { "validated": true, "verification_file": true } ``` *Validation only (verification_file=false):* ```json { "validated": true, "verification_file": false } ``` ## Event Processing ### Single Service Configuration When only one service is configured, events are sent to that service. If the service fails, events are spooled for retry. ### Multi-Service Configuration When multiple services are configured: 1. Each enabled service receives the event independently 2. If a service fails, it generates its own spool message for retry 3. Each service can have different bucket/container and prefix configurations ### Spooling and Retry - Each service failure generates a separate SQS message for retry - Spooled events contain service-specific metadata (bucket, prefix, credentials) - The unspooler processes each service's failed events independently - File-based spooling creates separate paths for each service configuration ## Migration Guide ### From Legacy to Service-Based Configuration 1. **Keep existing configuration**: Legacy configuration continues to work 2. **Add services object**: Gradually migrate to service-based configuration 3. **Test thoroughly**: Validate both configurations work as expected Example migration: **Before:** ```json { "firehose": { "enabled": true, "credential_id": "507f1f77bcf86cd799439011", "bucket": "my-bucket" } } ``` **After:** ```json { "firehose": { "enabled": true, "services": { "aws": { "enabled": true, "credential_id": "507f1f77bcf86cd799439011", "bucket": "my-bucket" } } } } ``` - name: Account description: > The authenticated user reveals the details of the API caller's user account as well as certain details about the account of which the user is member. The `products` array reveals all ActiveProspect products and to which the caller's account is subscribed. - name: Connections description: Account connections with other LC accounts - name: System - name: Changelogs description: | 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. - name: Credentials description: | 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. - name: Reports description: '' - name: Routers description: '' - name: Types x-traitTag: true description: > A type defines the kind of data LeadConduit expects in a field or in a data point appended to a lead by any LeadConduit integration. LeadConduit uses a field's type to understand a value submitted with a lead. Types are simple and are all provided "out of the box" by LeadConduit. You cannot add or remove types. Standard LeadConduit fields are properly typed. If you need to create a custom field for some reason, you can set the type. A field's type... * determines whether a field's value is valid * normalizes the formatting of a value * parses a value into it's constituent components for use in flow rules and mappings * protects consumer PII by masking sensitive information before LeadConduit stores it * preserves the raw value submitted to LeadConduit, just in case ## Boolean Boolean fields and variables are declared as type `boolean`. | Component | Type | Description | | --------------- | ---- | ----------- | | `raw` | string | Unmodified field value submitted with the lead | | `valid` | boolean | Indicates whether the value could be understood as a boolean | | `normal` | boolean | The normalized value (i.e. `"Yes"` is normalized to `true`) | ## City City fields and variables are declared as type `city`. ## Credential Credential fields and variables are declared as type `credential`. ## Date Date fields and variables are declared as type `date`. | Component | Type | Description | | --------------- | ---- | ----------- | | `raw` | string | Unmodified value submitted with the lead | | `valid` | boolean | Indicates whether the value could be understood as a date | | `normal` | string | The normalized value (i.e. `"10/1/1988"` is normalized to `"1988-10-01"`) | ### Supported Formats | Format | Example | | ------ | ------- | | `ddd MMM DD YYYY` | `"Mon Jun 02 2014"` | | `MMM DD YYYY` | `"Jun 02 2014"` | | `M/D/YYYY` | `"6/2/2014 or 06/02/2014"` | | `M/D/YY` | `"6/2/14"` | | `YYYY-MM-DD` | `"2014-06-02"` | | `MM-DD-YYYY` | `"06-02-2014"` | | `MMDDYYYY` | `"06022014"` | | `YYYYMMDD` | `"20140602"` | | `"ddd DD MMM YYYY` | `"Fri 18 July 2014"` | | `"DD MMM YYYY"` | `"18 July 2014"` | | `"D/M/YYYY"` | `"18/7/2014"` | | `"D/M/YY"` | `"18/7/14"` | | `"YYYY-DD-MM"` | `"2014-18-07"` | | `"DD-MM-YYYY"` | `"18-07-2014"` | | `"DDMMYYYY"` | `"18072014"` | | `"YYYY-DD-MM"` | `"2014-18-07"` | | `"YYYYDDMM"` | `"20141807"` | ## Date of Birth Date of birth fields and variables are declared as type `dob`. See the [date type](/docs/leadconduit/api/tag/Types/#tag/Types/section/Date) for supported formats. | Component | Type | Description | | --------------- | ---- | ----------- | | `raw` | string | Unmodified value submitted with the lead | | `valid` | boolean | Indicates whether the value could be understood as a date | | `normal` | string | The normalized value (i.e. `"10/1/1988"` is normalized to `"1988-10-01"`) | ## Email Email fields and variables are declared as type `email`. | Component | Type | Description | | --------------- | ---- | ----------- | | `raw` | string | Unmodified value submitted with the lead | | `valid` | boolean | Indicates whether the value could be understood as an email address | | `normal` | string | The normalized value (i.e. `"MIKEJONES32@gmail.com"` is normalized to `"mikejones32@gmail.com"`) | | `user` | string | User name (everything to the left of @) | | `domain` | string | Domain name (everything to the right of @) | | `host` | string | Domain excluding top level domain | | `tld` | string | Top level domain (.com, .net, etc) | | `is_free` | boolean | Whether or not the email is from a free domain (ex: gmail, yahoo, etc) | | `is_disposable` | boolean | Whether or not the email is disposable | ## First Name Email fields and variables are declared as type `first_name`. ## Gender Gender fields and variables are declared as type `gender`. Values are parsed case insensitively. Examples of valid gender values are: "male", "m", "female", "f", "other", "o". | Component | Type | Description | | --------------- | ---- | ----------- | | `raw` | string | Unmodified value submitted with the lead | | `valid` | boolean | Indicates whether the value could be understood as a gender | | `normal` | string | The normalized value (`"male"`, `"female"`, `"other"`) | | `abbr` | string | Abbreviation of the `normal` value (`"M"`, `"F"`, `"O"`) | ## Last Name Last name fields and variables are declared as type `last_name`. ## Number Number fields and variables are declared as type `number`. Decimal and negative numbers are supported. Currency and unit punctuation characters are ignored. | Component | Type | Description | | --------------- | ---- | ----------- | | `raw` | string | Unmodified value submitted with the lead | | `valid` | boolean | Indicates whether the value could be understood as a number | | `normal` | number | The normalized value (i.e. `"$100.99"` is normalized to `100.99`) | ## Phone Phone fields and variables are declared as type `phone`. This data type only supports US phone numbers. | Component | Type | Description | | --------------- | -------- | ----------- | | `raw` | string | Unmodified value submitted with the lead | | `valid` | boolean | Indicates whether the value could be understood as a phone number | | `normal` | string | The normalized value (i.e. `"(281) 330-8004"` is normalized to `"2813308004"`) | | `area` | string | Area code portion of the phone number (i.e. `"281"`) | | `exchange` | string | Exchange portion of the phone number (i.e. `"330"`) | | `line` | string | Line number portion of the phone number (i.e. `"8004"`) | | `number` | string | Full number (i.e. `"3308004"` | | `extension` | string | Phone number extension (i.e. `"2813308004x201" has extension `"201"`) | | `type` | string | Phone number type based on hint `m`, `h`, or `w` appended to the number- (i.e. `"(281) 330-8004m"` has type of `"mobile"`) | | `is_tollfree` | boolean | Phone has an `area` of 800, 844, 855, 866, 877, or 888 | ### Supported Formats | Format | Description | | ------ | ------- | | `"2813308004"` | Ten-digit phone number | | `"281-330-8004"` | Ten-digit phone number with dashes | | `"281.330.8004"` | Ten-digit phone number with dots | | `"281 330 8004"` | Ten-digit phone number with spaces | | `"(281) 330-8004"` | Ten-digit phone number with parentheses, space, and dash | | `"1 (281) 330-8004"` | Any supported format with preceding country code | ### Line Type Hint If a raw phone number value has line type hint appended, the phone type will automatically set the `type` value appropriately. For example, the `c` hint found in `281-330-8004 (c)` (c indicates "cell") will cause the `type` value to be set to "mobile". Hints can immediately follow the phone number, can be separated by the phone by any number of spaces, and can also optionally be wrapped in parentheses. | Phone Number | `type` Value | | ------------ | ------------ | | `"2813308004c` | "mobile" | | `"2813308004m` | "mobile" | | `"2813308004 m` | "mobile" | | `"2813308004 (m)` | "mobile" | | `"2813308004w` | "work" | | `"2813308004h` | "home" | ### Extension Hint If a raw phone number value has an extension hint appended, the phone type will automatically set the `extension` value appropriately. For example, the `x201` hint found in `281-330-8004 x201` will cause the `extension` value to be set to `"201"`. Hints can immediately follow the phone number, can be separated by the phone by any number of spaces. ## Postal Code Postal Code fields and variables are declared as type `postal_code`. | Component | Type | Description | | --------------- | -------- | ----------- | | `raw` | string | Unmodified value submitted with the lead | | `valid` | boolean | Indicates whether the value could be understood as a postal code | | `normal` | string | The normalized value (i.e. `"78704 4224"` is normalized to `"78704-4224"`) | | `country_code` | string | Two letter country abbreviation (i.e. `"US"`) | | `zip` | string | First 5 digits of a US zip code (i.e. `"78704"`) | | `four` | string | Last 4 digits of a US zip code (i.e. `"4424"` | | `fsa` | string | Canadian forward sortation area (i.e. `"Q2E 4U7"` has `fsa` of `"Q2E"`) | | `ldu` | string | Canadian forward sortation area (i.e. `"Q2E 4U7"` has `fsa` of `"47U"`) | | `outcode` | string | Great Britain outward code (i.e. `"A1 1AA"` has `outcode` of `"A1"`) | | `incode` | string | Great Britain inward code (i.e. `"A1 1AA"` has `incode` of `"1AA"`) | ## Range Range fields and variables are declared as type `range`. A range is a field value with lower and upper numeric boundaries. Range fields are commonly used in scenarios where a consumer is presented a drop-down. For example, the standard `credit_score` range field might have the value `"700 - 749"`. | Component | Type | Description | | --------------- | -------- | ----------- | | `raw` | string | Unmodified value submitted with the lead | | `valid` | boolean | Indicates whether the value could be understood as a range value | | `normal` | string | The normalized value (i.e. `"700 to 749"` is normalized to `"700-749"`) | | `min` | number | The lower boundary of the range (i.e. `700`) | | `max` | number | The upper boundary of the range (i.e. `749`) | | `avg` | number | The average of the `min` and `max` accurate to the second decimal place (i.e. `724.50`) | | `mid` | number | Average of max and min, rounded down to the nearest whole number (i.e. `724`) | ## SSN US Social Security Number fields and variables are declared as type `ssn`. | Component | Type | Description | | --------------- | -------- | ----------- | | `raw` | string | Unmodified value submitted with the lead | | `valid` | boolean | Indicates whether the value could be understood as a Social Security Number | | `normal` | string | The normalized SSN value (i.e. `"1234567890`") | | `first_three` | string | First three digits of SSN (i.e. SSN `"123-456-7890"` has `first_three` of`"123"`| | `middle_two` | string | Middle two digits of SSN (i.e. SSN `"123-456-7890"` has `first_three` of`"456"`| | `last_four` | string | Last four digits of SSN (i.e. SSN `"123-456-7890"` has `first_three` of`"7890"` | ## State Locality or State fields and variables are declared as type `state`. | Component | Type | Description | | --------------- | -------- | ----------- | | `raw` | string | Unmodified value submitted with the lead | | `valid` | boolean | Indicates whether the value could be understood as a locality or state | | `normal` | string | The normalized locality or state. US states and territories are normalized to their two letter code (i.e. `"TX"`) | | `name` | string | Full name of the locality or state (i.e `"Texas"`) | ## String String fields and variables are declared as type `string`. ## Time Time fields and variables are declared as type `time`. - name: Rules x-traitTag: true description: > LeadConduit uses a rules engine to customize flow behavior based on field data, appended data, or internal tracking metadata (such as the submission timestamp). The rules engine is built into flow acceptance criteria, filtering, volume caps, pricing, mappings, and more. ### Rule Set Rules belong to a set which has the following properties: * `op` — `and` or `or` determines whether all rules in set must pass or just one * `rules` — the array of Rules and/or Rule Sets to evaluate ### Rules Each element of the `rules` array can be a Rule or another Rule Set. Rules have the following properties: * `lhv` — left hand value is a key to look up a value from the lead data context * `op` — operator Name of the operator * `rhv` — right hand value (omit for unary operators like `is blank`) * `rule_set` — optional rule set to be ANDed with the rule ### Variables When rules are processed the `lhv` will be resolved to a value using the data in the variables found under that key. For example, if the `lhv` is "lead.first_name" and the variables are `{ "lead": { "first_name": "Bob" } }`, then the resolved `lhv` will be "Bob". ### Templating The `lhv` and `rhv` of each rule supports (templating)[/docs/leadconduit/api/tag/Templates/]. The variables are used to evaluate the template. - name: Invitations description: Invite another account to connect - name: Onboards description: > Onboards are records that track the buyer connection onboarding process in LeadConduit. When a buyer accepts an invitation to connect with a seller, an onboard record is created to manage and track the setup workflow. ## Overview The onboarding process involves: 1. **Creating an Onboard** - When a buyer accepts a connection invitation, an onboard record is created with status `created`. Optionally, the UI can send a `flow_id` if already available 2. **In Progress** - The UI sends a PUT with the user's `flow_id` and status `in_progress` 3. **Completing Setup** - The UI must send a PUT with status `completed` to notify the backend that the onboard process is finished. The backend then calls `/onboard/buyer` to finish the flow synchronization **Note:** The `/onboard/buyer` endpoint can also be called directly by the UI modal when the user has already completed a previous onboard process. ## Onboard Statuses | Status | Description | |--------|-------------| | `created` | Initial state when the onboard is first created | | `in_progress` | The UI has sent the user's `flow_id` | | `completed` | The backend triggers the buyer delivery setup by calling `/onboard/buyer` | | `failed` | The setup process encountered an error | ## Buyer Setup Process The backend automatically triggers the buyer delivery setup when the onboard status is set to `completed`. This process performs: 1. **Connection Validation** - Verifies the connection exists and hasn't already been set up 2. **Seller Flow Discovery** - Finds all seller flows that have a buyer step pointing to this buyer 3. **Buyer Flow Setup** - Creates or updates the buyer's flow to receive leads from the seller 4. **Seller Flow Updates** - Adds the buyer's `flow_id` to the seller's flow mappings 5. **Notifications** - Sends email notifications to seller account users about the new connection 6. **Connection Flagging** - Marks the connection as having buyer delivery configured - name: Variables x-traitTag: true description: | 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. - name: Caps and Limits description: > LeadConduit supports two controls that set constraints on lead submissions and pings. ### 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. - name: Lead Submission x-traitTag: true description: |+ How lead handling works - name: Templates x-traitTag: true description: > LeadConduit supports combining, [formatting](/docs/leadconduit/api/tag/Templates/#tag/Templates/section/Variable-Formatting), [hashing](/docs/leadconduit/api/tag/Templates/#tag/Templates/section/Variable-Hashing), and [performing math](/docs/leadconduit/api/tag/Templates/#tag/Templates/section/Variable-Math) on values using template markup. Templating in LeadConduit is based on the popular [Handlebars](https://handlebarsjs.com/) semantic templating library. A template is a string which contains any number of variable placeholders ## 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](/docs/leadconduit/api/tag/Variables/) available to a template depends on the [fields](/docs/leadconduit/api/tag/Fields/) defined in your flow and the steps you've added to your flow. ## 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. ### 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 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". #### 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 #### 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 june 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 ### 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'. ### Converting Number and Boolean to String Fields of type number and boolean can be converted to string using the `format` helper with the `dataType="String"` option: `{{format field_name dataType="String"}}` Example: - Input: `{{format lead.age dataType="String"}}` with `lead.age` = 30 - Output: "30" ### Converting String to Number Fields whose final result from the `format` helper is a string can be converted to a number if the `dataType="Number"` option is passed and the value is a string representing a valid number. Examples: - Input: `{{format lead.postal_code dataType="Number"}}` with `lead.postal_code` = '78751' - Output: 78751 (as a number value) If the string does not represent a valid number, the result will not be converted: - Input: `{{format lead.postal_code dataType="Number"}}` with `lead.postal_code` = 'H3Z 2Y7' - Output: 'H3Z 2Y7' This can also be used with dates if the formatting returns only numbers, such as epoch time: - Input: `{{format lead.source_timestamp format="X" dataType="Number"}}` with `lead.source_timestamp` = '2015-06-24T17:24:49.060Z' - Output: 1435166689 (as a number value) ## Variable String Manipulation Strings can be manipulated with the following helpers: ### Lowercase Transforms the value to lowercase: `{{lowercase field_name}}` Example: - Input: `{{lowercase lead.first_name}}` with `lead.first_name` = "Mike" - Output: "mike" ### Uppercase Transforms the value to uppercase: `{{uppercase field_name}}` Example: - Input: `{{uppercase lead.first_name}}` with `lead.first_name` = "Mike" - Output: "MIKE" ### Substring Returns a substring from the start position to the end position, or from the start position to the end of the string if no end position is provided: `{{substring field_name start="3"}}` Example: - Input: `{{substring lead.first_name start="3"}}` with `lead.first_name` = "Michael" - Output: "chael" `{{substring field_name start="2" end="4"}}` Example: - Input: `{{substring lead.first_name start="2" end="4"}}` with `lead.first_name` = "Michael" - Output: "ich" ### Replace Replaces the pattern with the content of the replace option. The pattern can be a literal string or a regular expression using the `regexp()` option: `{{replace field_name pattern="Mi" replace="At"}}` Example: - Input: `{{replace lead.first_name pattern="Mi" replace="At"}}` with `lead.first_name` = "Michael" - Output: "Atchael" `{{replace field_name pattern="regexp(h.{3})" replace="ke"}}` Example: - Input: `{{replace lead.first_name pattern="regexp(h.{3})" replace="ke"}}` with `lead.first_name` = "Michael" - Output: "Micke" ### Extract Extracts all occurrences found with the regular expression in the pattern: `{{extract field_name pattern="\$begin:math:display$(.*?)\\$end:math:display$"}}` Example: - Input: `{{ extract foo pattern="(?<=#)(\\w+)(?=#)" }}` with `lead.first_name` = "#John#Doe#Smith" - Output: "John Doe" ## 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 "grade-school 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](#variable-math-formatting). ### 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. ## 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 the following hashing algorithms are supported: * md4 * md5 * ripemd * ripemd160 * sha1 * sha224 * sha256 * sha384 * sha512 * whirlpool 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: * `hex` (default) * `base64` * `latin1` externalDocs: url: https://developers.activeprospect.com/ description: ActiveProspect Developer Portal paths: /ping_limits/{id}: get: tags: - Caps and Limits summary: Fetch a ping limit counter description: Get a counter for a single ping limit. operationId: getPingLimits parameters: - in: path name: id description: The ID of the specific Ping Limit schema: $ref: '#/components/schemas/ID' required: true responses: '200': description: OK content: application/json: schema: $ref: '#/components/schemas/PingLimit' components: schemas: ID: type: string description: 24 character alpha-numeric BSON identifier pattern: ^[0-9a-fA-F]{24}$ readOnly: true example: 5fd4371e940df5a34a3888b2 PingLimit: x-tags: - Caps and Limits title: Ping Limit description: >- The ping limit configuration is defined in a flow on a source, or directly on the flow itself. The configuration controls the behavior of the ping limit by setting the maximum and the duration. The counter for a ping limit is kept as a standalone record which shares ping limit's ID. type: object properties: id: $ref: '#/components/schemas/ID' name: type: string description: The human-readable name of the ping limit maximum: type: integer description: The number of pings that will be accepted duration: type: integer description: The number duration_units the ping limit persists for duration_units: type: string description: >- The unit of time the ping limit persists for: minute, hour, day, week, or month time_zone: type: string description: The time zone in which ping limit resets example: America/New_York created_at: $ref: '#/components/schemas/Timestamp' description: Read-only time the ping limit was created readOnly: true Timestamp: type: string format: date-time securitySchemes: APIKey: type: http scheme: basic description: > LeadConduit uses [HTTP Basic Authentication](https://en.wikipedia.org/wiki/Basic_access_authentication) with the username `API` and your API key as the password. For example: `API:1f1b96c9150d8050e858c043d543bb4eadae0e6f`' ````