What you will build
One automation with four parts:- A trigger for the moment worth reporting
- An HTTP Request task that POSTs JSON to your endpoint, authenticated with a bearer token
- A described response, so what the endpoint sends back becomes fields
- A later task that uses one of those fields
This recipe sends data out of HireData. If what you actually need is the other direction — another tool sending data in to start an automation — that’s a custom app trigger instead. See Custom Apps and Set up a trigger.
What to ask for before you start
Whoever owns the endpoint has all of this. Getting it up front saves a round of guessing:- The URL to call, and the method it expects
- The body it expects, ideally as a sample JSON payload rather than a description
- How it authenticates. This recipe uses a bearer token issued for this integration, not anyone’s personal one
- What it returns — both when a call is accepted and when it’s rejected
- Whether there’s a test or sandbox address. The test in step 7 sends a real request, so you want somewhere safe to aim it
Build the automation
1. Trigger on the moment worth reporting
Open the Start block. Choose HireData as the app, then Conversation as the object and Ended as the trigger. The automation now runs once each time a conversation finishes. Any trigger works here — a completed form response, a candidate updated in your ATS. It only changes which fields you have available to send in step 4; the rest of the recipe is the same.2. Add the HTTP Request task
Add a task and pick HTTP Request. It’s filed under both Add and Message, and both routes open the same task — see where to find the task. If you were given a specification or a cURL command when you asked for the endpoint’s details, click Import in the drawer’s footer now and let HireData fill the request in. The two routes fill in different things, so check what an import fills in, then read back through steps 3 to 6 against what it wrote. Otherwise, fill it in by hand as below.3. Set the method and the URL
A new task already has the method set toPOST, which is what you want. Enter your endpoint’s address in the URL bar:
4. Build the JSON body from automation fields
Open the Body tab and add a property per value you want to send. Beside each Value is a field picker: use it to pick a field from the run rather than typing a fixed value, so each run sends its own data. Dots in a property name nest it, so a body like this needs six properties:
A conversation groups the people in it under Sender, Receiver, and Owner, so pick from whichever side the candidate is on: the sender when they started the conversation, the receiver when your automation did. On the sender’s side, which contact detail is filled in follows the channel — a phone number on WhatsApp, an email address on email.
More generally, which fields you can pick depends on the trigger you chose in step 1, and includes values that earlier tasks in the same automation produced. What arrives at your endpoint is ordinary JSON:
5. Authenticate with a bearer token
Open the Auth tab, selectBearer token, and paste the token into Token. HireData sends it as an Authorization header on every request; there’s no header for you to add on the Headers tab.
If the endpoint wants a key in a named header or a query parameter instead, or trades a client ID and secret for a token, the other types cover both — see authentication.
6. Describe what comes back
Two things to do before the response is usable, and it’s easier in this order. Start on the Advanced tab and write a Description — “Post conversation outcome” for this task. It titles the task everywhere else, and it’s the first half of the name of every field this task produces, so settling it now saves re-reading a picker full of renamed fields later. Then, in the Response section beneath the tabs, describe the body your endpoint returns. Say it answers a successful call with this:id, labelled “Event ID”, and one for status, labelled “Status”. Later tasks can now pick these two by name:
Post conversation outcome: idPost conversation outcome: status
id is what saves a later task from digging it out of that text.
Under Error response (non-2xx), describe what the endpoint returns when it rejects a call — usually a message you’d want in a log. That tree is only worth filling in if you set the run to continue past a failure — see Decide what happens when the call fails below.
A value you don’t describe here is a value no later task can pick out by name. See describe the response.
7. Test the request before you activate
Click Test in the footer, and read the warning before you click Send. The dialog asks for one value per parameter, grouping them by where they belong. This recipe’s request has no path or query parameters, so you’ll see a Body group only, one input per property from step 4. Anything you set to a fixed value in step 4 is already filled in. The properties you bound to automation fields come up blank, because those values only exist during a real run — type a plausible literal into each of those. See fill in the values. Click Send. You get back a status word, the HTTP code, and how long the call took, plus the full response body — and an Outputs section listing the values HireData pulled out using the tree you built in step 6. Read those against each other. A property you described that comes back missing shows up here, and this is the cheapest moment to find that out.8. Use a response value in a later task
Add a task after the HTTP Request that does something with what came back. Add → Note is the simplest: putPost conversation outcome: id in the note’s text, so the reference your own system generated is recorded in HireData too.
Any later task that takes a text value works the same way. The pattern is what matters: the endpoint’s answer is now data in the run, not something you have to go and look up. See use a response value in a later task.
Decide what happens when the call fails
Your endpoint will be unavailable at some point. Two switches on the Advanced tab decide what that costs you, and for this recipe:- Leave Fail on error responses on. If your endpoint rejects the payload, you want the task to say so.
- Turn Continue automation on failure on only if this POST is a notification and the rest of the run is worth doing without it. If you do, fill in the Error response (non-2xx) tree as well, so a later task can log what your endpoint actually said.
Activate and check the first runs
Activate the automation and let a real conversation end. Then open Runs and find the run. A completed HTTP Request shows its description as the title, with What will you provide? and What will you get back? beneath it, so you can compare what was sent against what you configured. See what the task looks like in a run and the Runs log. Check the first few runs against your own system’s records before you rely on the automation. A request that succeeded from HireData’s side still tells you nothing about what your system did with it.Need more help?
If the automation isn’t running at all, the problem is the trigger rather than the request. See Why didn’t my automation run?. If the request runs but comes back blocked, see if a request comes back blocked. If you still need help, contact support@hiredata.com and include:- The automation name and a link to a run
- The task’s method and URL, with the token removed
- What you expected your endpoint to return, and what it returned instead