Send Yirlo replies and hot leads to Pipedream

How the Pipedream connection works

Yirlo handles the answers that come back from your outbound emails: it sorts them and writes draft responses. Whenever a person actually writes back, a reply.received event goes to the webhook address you configured. If that person is interested, a hot_lead.received event follows. Each payload is signed using HMAC-SHA256, with the result placed in the X-Yirlo-Signature header.

Pipedream's HTTP / Webhook trigger gives you a unique URL that starts a workflow on every request. That is all the plumbing you need. From there you can add any of Pipedream's app steps, such as Slack, Google Sheets, HubSpot, Salesforce, Pipedrive, Airtable or Notion, or write a Node.js or Python step of your own.

This fits teams that already run their operations in Pipedream and want sales replies handled in the same place as everything else. A listed Yirlo app in Pipedream-style marketplaces is coming soon. Until then, the webhook works the same way for every tool and takes a few minutes to set up.

Set it up in five steps

Plan for about ten minutes the first time. Have a Pipedream account and your Yirlo project open in two tabs.

• In Pipedream, create a new workflow and choose the HTTP / Webhook trigger. Copy the unique URL it shows.
• In Yirlo, open the Integrations area, add a webhook, and paste that URL. Choose reply.received, hot_lead.received, or both.
• Press Send test event in Yirlo. A sample event arrives in Pipedream and shows up under the trigger, so you can select it and see every field.
• Add your steps. Start with a code step that checks the signature (next sections), then add app steps that use the fields from the sample.
• Deploy the workflow. From then on, each real reply and hot lead runs it automatically.

The fields in each event

Each payload describes one lead and their message. It gives the person's email, name and company, tells you which campaign the message came from, and includes what they wrote. Hot lead payloads contain the same data, which lets a single workflow serve both.

Pipedream shows the incoming JSON as a tree under steps.trigger.event.body. Because the test event is a real sample, the exact field names appear there, and you can click them to insert them into later steps. Map them as you would in any app step: the email into a contact lookup, the company into a deal name, the reply text into a note or a Slack message.

Yirlo emails one decision maker per company, so each event maps to one person at one company. That keeps CRM logic simple: a single contact and a single account per event, with no deduplication across several contacts at the same company.

Checking the X-Yirlo-Signature in a code step

A webhook URL can be called by anyone who finds it. The signature lets your workflow confirm that a request came from Yirlo and that the body arrived unchanged. Put the check first, right after the trigger, and stop the workflow when it fails.

Yirlo computes an HMAC-SHA256 of the request body with your webhook's signing secret and sends the result in X-Yirlo-Signature. In Pipedream, store the secret as an environment variable, and set the HTTP trigger to include the raw body, because the check has to run on the exact bytes Yirlo sent rather than on re-serialized JSON.

A Node.js code step looks like this in plain terms: import crypto, read the raw body from the trigger event and the header from steps.trigger.event.headers, then build the expected value with crypto.createHmac('sha256', process.env.YIRLO_SECRET).update(rawBody).digest('hex'). Compare it to the header using crypto.timingSafeEqual on two buffers of equal length, and call $.flow.exit('invalid signature') when they differ.

Yirlo's API documentation (yirlo.com/api-docs) spells out how the signature value is encoded, so copy the digest format from there. When the check fails on the sample event, look first at the encoding, then at which body you hashed.

Workflows worth building

Once the signature step passes, the rest is ordinary Pipedream work. These are the patterns teams reach for first with replies and hot leads.

A hot lead alert is the quickest win. Post the lead's name, company, campaign and reply text to a Slack channel, with a link to the conversation in Yirlo, so the right person answers within minutes.

A CRM record is the next one. Look up the contact by email in HubSpot, Salesforce or Pipedrive, create it when it is missing, then open a deal or add a note with the reply text. Yirlo's hot leads go into any CRM this way, and Pipedream's code steps handle odd field mappings that a simple connector would struggle with.

A running log suits teams that live in spreadsheets. Append a row to Google Sheets or Airtable for every reply.received event, with columns for email, company, campaign and the reply. Filter on hot_lead.received to build a second tab of only the interested leads.

Route by campaign

Each event names the campaign that produced the reply, and that is a useful branch point. A company running one campaign for finance teams and another for engineering leaders can send the first to one account owner and the second to another, using Pipedream's conditional steps or a short switch in code.

The campaign field also helps with reporting. Tally replies by campaign in a Sheets or database step to see which audiences respond, in addition to the summary emails Yirlo sends 3 times weekly.

Pulling hot leads on a schedule instead

Webhooks push events as they happen. Some workflows prefer to pull. The Yirlo API, authenticated with an X-API-Key header, can read hot leads and the inbox, so a Pipedream workflow with a Schedule trigger can fetch them every morning and write a digest.

Many teams use both: the webhook for instant alerts and a scheduled API read as a daily check that nothing was missed. The API also lets a workflow add a note or set a lead's status in Yirlo after your CRM step finishes, so both systems agree on where each lead stands.

Keeping the workflow reliable

Keep the first step fast. Verify the signature, then hand off to the slower steps. Use Pipedream's built-in error handling and retries on app steps so a temporary CRM outage does not drop a hot lead.

Handle both event types deliberately. If you subscribed to reply.received and hot_lead.received, check the sample event to see how the type is carried and branch on it, so an interested reply is not logged twice as two different things.

Rotate the signing secret by updating the Pipedream environment variable together with the value in Yirlo. Re-run Send test event after any change to confirm the signature step still passes.

Questions

Related