Skip to main content
A trigger is a web address your other tool sends data to. This article walks through the trigger page from top to bottom: creating the trigger, describing its fields, testing it, and connecting automations. If you haven’t created a custom app yet, start with the introduction.

​
Create a trigger

On your app’s edit page, click Create Trigger. Name it after the data it will receive, for example “New application” or “Candidate updated”. The trigger opens in its editor. At the top you’ll find:
  • The trigger’s name and its address bar with the request method
  • Try It to send a test request
  • Automate This to create an automation from the trigger
  • The Activate or Pause button

​
Choose the method and share the address

Click Copy address and paste the address into the tool that will send the data. The request method tells HireData what kind of request to expect: Requests with a different method than the one configured are rejected.

​
Describe the fields you’ll receive

The Fields we receive list tells HireData what’s inside the data, so you can use it in automations and as variables. Each field has:
  • Label: a readable name, like “Contact: First Name”
  • Key: the identifier in the data, with dots for nested values, like contact.firstName
  • Type: what kind of value to expect, like text, a number, or a date
There are three ways to build the list:
While the trigger has no fields yet, click Upload Sample Object and paste or upload a JSON example of the data you’ll send. HireData creates the fields for you and detects emails, phone numbers, dates, and URLs automatically.
Once a trigger has fields, new requests no longer change them. Edit the list manually or clear it before uploading a new sample.

​
Test it with Try It

Click Try It in the trigger’s header to send a request without leaving HireData:
  1. The form is pre-filled with example values based on your fields. Adjust anything you like.
  2. Click Send.
  3. Check the request on the left and the response on the right.
The Mode switch above the form chooses how the request is handled:
  • Test (default): creates a test event and runs your automations in a safe sandbox. You can follow every step and its outcome, but nothing is created, changed, or sent.
  • Live: sends a real request, exactly as your other tool would.
Test events and their runs show a Test label in the Events tab.

​
Hand it to your developer

If someone else manages the tool that will send the data, the Request Examples at the bottom of the trigger give them everything they need. You can copy:
  • cURL: a ready-to-run example request for the command line
  • JSON: an example of the data the trigger expects
  • OpenAPI: a schema that imports into tools like Postman
  • Copy for LLMs: a single document describing the trigger, made to paste into an AI assistant that’s building the integration for you
Selecting fields first limits the copies to just those fields.

​
Sending test requests

Any request can be marked as a test by adding a header:
Test requests behave exactly like Try It’s Test mode: automations run in a safe sandbox that doesn’t create, change, or send anything, and the event shows a Test label in the Events tab. Useful while the other tool’s integration is still being built.

​
Sync people

If the incoming data describes a person, like a candidate or a contact, the People section maps it onto person records in HireData:
  1. Click Add Person and map the fields.
  2. Every request to the trigger now syncs that person automatically.
  3. Automations using the trigger can use the person directly, for example as the receiver of an email, without mapping fields again.
Remove all people to stop syncing.

​
Turn it into automations

Click Automate This in the trigger’s header to create a draft automation that starts whenever the trigger receives data. You can configure its steps right after. The trigger’s tabs show everything it does in one place:
  • Automations: the automations connected to this trigger, with bulk activate, pause, duplicate, and delete
  • Events: every request the trigger received
  • Runs: the automation runs those events started
  • Tasks: the individual tasks those runs executed

​
How requests are handled

A quick reference for when something doesn’t behave as expected:
  1. The request method must match the trigger’s configured method, otherwise it’s rejected.
  2. Every valid request is stored as an event, even while the app or trigger is paused. You’ll always see it in the Events tab.
  3. Automations only run when both the app and the trigger are active. If nothing happens, check those two switches first, then the automation’s own status and start filters.
  4. Requests with the X-HireData-Test: true header are stored as test events and run automations in a sandbox, without live changes.
  5. While a trigger has no fields, its first request is used to create them automatically.

​
Still need help?

If a trigger isn’t behaving as expected, contact our team at support@hiredata.com and include:
  • A link to the trigger
  • The event, from the Events tab
  • The automation you expected to run

Related topics

Create a Vincere automation in HireDataCreate a Carerix automation in HireDataCreate an OTYS automation in HireDataLogging WhatsApp conversations in Carerix with HireDataLogging Email Messages on Carerix with HireData