Follow

LeadConduit: Response Parsing

What is Response Parsing?

Sending data to a recipient via a LeadConduit Delivery step takes the form of an exchange of messages between LeadConduit and the recipient. First, LeadConduit sends a Request message to the recipient. This message contains the lead data. The recipient replies back to LeadConduit with a Response message that describes the outcome of the request.

The recipient of every Custom Delivery responds differently when data is sent to them. Exactly what that response is, is determined by the programmer who designed the recipient's platform. While there are some common formats (XML, Json, HTML, plain text) there is no universal, standard response content.

If you know your recipient's response format and content options you can configure LeadConduit's Custom integrations to parse each lead's response to identify whether the recipient has accepted or rejected the lead, and in the case of rejected leads, to extract the rejection reason if the recipient supplies it. This information is typically found in the recipient's posting instructions.

This article outlines basic concepts and parsing techniques for common response formats. In reality each implementation is unique, so its unlikely that you will be able to simply cut and paste a solution from this article.

Before We Begin: Content-Types

LeadConduit needs to know what format the response body will be in so it can use appropriate pattern-identifying rules to parse the response. If the response has been sent with a "Content-Type" header, LeadConduit will expect the content of the response body to be in the specified format. If no Content-Type header is present, LeadConduit will attempt to guess the Content-Type.

If the response Content-Type is Json and the response body is in fact well-structured Json, use "Dot Notation" to locate the outcome and rejection reason portions of the response body. If the Content-type is XML and the response body is in fact well-structured XML, use "X-path" notation. If HTML, then use CSS selectors. Finally, if Content_Type is plain text, is not discernible or is not well-structured according to the response's Content-Type header, use "Regular Expressions". These notation methods are explained in detail in other articles linked below.

The Response-related Mappings: Outcome Search Term, Outcome Search Path, and Reason Path

Three special mappings in your Delivery step tell LeadConduit how to parse the response body:

Outcome Search Term is whatever string value in the response body indicates that the lead was accepted by the recipient. It is often a simple word like "accepted" or "success".

Outcome Search Path is a Dot Notation, Xpath, Regular Expression or CSS selector that defines a location in the response body where LeadConduit should expect to find the Outcome Search Term. If an Outcome Search Path is mapped, then LeadConduit will only look at that location for the Outcome Search Term. If you are certain that the Outcome Search Term will occur only in the response body for accepted leads and never otherwise, you may optionally not map the Outcome Search path and LeadConduit will by default search the entire response body for the Outcome Search Term. However, best practice is to map an Outcome Search Path whenever possible to avoid false positives.

Reason Path is a Dot Notation, Xpath, Regular Expression or CSS selector that defines a location in the response body where LeadConduit should expect to find the rejection reason string. Reason path is only invoked if the Outcome Search Term is not found.

Specific examples of these mappings will be shown in the following articles:

Parsing Json Response Bodies Using Dot Notation

Parsing XML Response Bodies Using XPath

Parsing HTML Response Bodies Using CSS Selectors

 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

You must be logged in to comment.