The Set node stores a value so you can use it later. Most often you take something out of a response and keep it: the advertiser’s ID for the lead, the URL to send the customer to, the price they quoted.
The value is written to the database, so it survives the run. It is available to the rest of the flow, and afterwards to tracking and postbacks.
How it works
Each line has two fields.
- Key is the variable you are writing into, in braces, for example
{external_id}.
- Value is what goes into it. Use the picker to take something an earlier node produced, or type a fixed value.
Key: {external_id}
Value: {parsedBody.applicationId}Read it left to right: put applicationId from the response into external_id. The name on the right is whatever the advertiser calls it in their response, so it will be different for every partner.
There is no Source setting. Where the value comes from is decided by what you pick, so a field from the response body is picked under the previous step rather than selected as “body” somewhere.
One node holds as many lines as you need, so a single Set node after a request usually stores everything you want from it:
Key: {external_id} Value: {parsedBody.applicationId}
Key: {redirect_url} Value: {parsedBody.offerUrl}Store the external ID
{external_id} is the advertiser’s own identifier for the lead, and it is the one value worth storing in almost every integration.
Once the lead is delivered, everything that happens to it afterwards happens on the advertiser’s side. When they later report that it was approved, rejected or paid, they refer to it by their own ID, because yours means nothing to them. If you never stored it, that report arrives with nothing to attach it to, and the conversion is never confirmed.
The same ID is also what stops the same conversion being counted twice. See Deduplication, Deduplication based on advertiser’s ID and Tracking S2S Postback.
Store it even when you cannot think of a use for it today. It costs one line, and there is no way to go back for it later.
Other variables worth knowing
{redirect_url}is where the customer goes next, when the advertiser returns a link.{price}is what the advertiser bid for the lead. You need it in an auction, where the bids decide who wins. See Pingtree Distribution.{reason}is why a lead was rejected. Worth setting on every rejection path, otherwise the lead lands in Error and tells you nothing. See Reject reason.{commission}is what the affiliate earns. You rarely set this in an integration, because commissions are normally worked out from the commission settings rather than from the advertiser’s answer.
Anything else you store is yours to name and use: a token the next request needs, a value you want to pass onwards, a flag you check in a later condition.
Reading from a response
The picker offers everything the earlier nodes produced. Under a previous step you will find its whole result, not only the body, so you can store the status code, a header, or the raw response just as easily as a parsed field.
{parsedBody.…}is the parsed body. Follow the structure with dots, and use a number for a position in a list, as in{parsedBody.offers.0.offerUrl}.{status}is the HTTP status code, which is worth storing when you want to see later what the advertiser actually answered.{body}is the raw response as text, for when it did not parse.{headers}are the response headers.
If everything you pick out of {parsedBody} comes back empty, check the parser on the HTTP request node before looking anywhere else.
Building a value for the next request
Storing a response is the common use, but a Set node is also how you prepare something the next node needs.
Joining two parameters before encoding them, for example, is a Set node followed by a Modify Field node:
Key: {auth0}
Value: {client_id}:{client_secret}A value can mix fixed text and references freely, which is what makes this work.
When the value depends on the answer
A Set node writes what you give it, every time. It has no conditions of its own, so to store one thing on one answer and something else on another, each case needs its own connection with a condition and its own Set node at the end of it.
That is fine for two or three cases. Beyond that the canvas fills up with nodes that all do nearly the same thing.
Modify Field is the better tool there, because the conditions sit inside the node. Twenty rejection responses mapped onto your own reasons is one Modify Field node with twenty lines, rather than twenty Set nodes and twenty connections.
The rule of thumb: Set node when the value is simply there, Modify Field when you have to work out what it should be.
An empty Set node is allowed
A Set node with no lines does nothing to the data, and that is sometimes what you want. On a branch where the answer is “we looked and found nothing”, it leaves the field empty and lets the flow carry on to the End node, which keeps that branch visible on the canvas instead of leaving a loose end.
Common mistakes
- The two fields swapped. Key is where the value lands, Value is where it comes from. The wrong way round, and you store the literal text into a variable named after a response field.
- Missing braces. A reference without braces is just text.
- Not storing
{external_id}. Everything looks fine until the first postback arrives and matches nothing.
