Triggering automation with webhooks

iHook is a module within the iDMS Power Suite that enables the creation of inbound webhook endpoints — publicly accessible URLs that allow external systems to push data directly into iMIS. When a third-party platform or custom application sends an HTTP POST request to an iHook endpoint, iWorkflow receives the payload and executes the configured actions: validating the incoming data, then inserting activity records or panel records into iMIS.

iHook is the modern replacement for the legacy iTransfer Webhooks (also called iTransfer Inbound Transfers). It is now accessed entirely through the iWorkflow user interface, using iWorkflow's Webhook trigger combined with specific iHook-compatible actions.

iHook is specifically designed for inbound data scenarios — where an external system needs to write data into iMIS in real time, without waiting for a scheduled batch process. This makes it ideal for event-driven integrations where something happens outside iMIS and that event needs to be immediately reflected inside it.

Understanding what iHook does

It is important to understand iHook's scope before building with it. The Insert Activity and Insert Panel Record actions used in iHook are fundamentally different from iUpdate. iHook is designed for third-party systems to insert new data into iMIS — it is not intended as a general-purpose record updater.

iHook is for: Receiving data from an external system and inserting a new activity or panel record into iMIS in response.

iHook is not for: Updating existing records, running complex queries, or replacing the functionality of iUpdate or iImport.

Licensing

iHook is an optional, separately licensed module. It requires iWorkflow as a prerequisite. If your organization currently uses iWorkflow, adding iHook extends it with the ability to receive inbound webhook data from external systems.

Use case

This tutorial walks through a scenario that associations with external event or registration platforms encounter regularly: automatically recording attendee check-ins from a third-party event app as activity records in iMIS.

Scenario: The association uses an external event check-in application on-site at conferences. When an attendee checks in, the app needs to immediately create a corresponding activity record in iMIS so that attendance is reflected in real time. Currently, staff export a spreadsheet at the end of each day and manually import it using iImport. The goal is to eliminate that manual step by having the check-in app send data directly to iMIS the moment each attendee checks in.

This is a strong use case for iHook because the trigger is an external real-time event (a check-in), the data originates outside iMIS, and the desired outcome is a new record (not an update to an existing one). The workflow will use a Webhook trigger to receive the check-in payload, a JSON Schema Validation action to confirm the data is well-formed, and an Insert Activity action to write the attendance record into iMIS.

📘

NOTE

Before building this workflow, confirm with your third-party vendor or developer that their system can send HTTP POST requests to a custom URL with a JSON body. This is the only technical requirement on the sending side. iHook handles everything on the iMIS side.

Understanding how iHook works: The Webhook trigger

Before building the workflow, it helps to understand how the Webhook trigger works and what the external system needs to send.

The webhook URL

When you add a Webhook trigger to an iWorkflow workflow and save it, iWorkflow automatically generates a unique, randomized URL for that workflow. This is the endpoint that the external system will POST data to.

The URL is not generated until the workflow is saved for the first time. Once saved, you can view and copy the URL from the Webhook trigger's properties pane in the workflow editor. The URL uses HTTPS and TLS 1.2 or higher.

⚠️

IMPORTANT

The webhook URL requires no API key, authentication header, or cookie. Security comes from the randomness of the URL itself — with roughly 2.9 × 10³⁷ possible combinations, it is computationally infeasible to guess. Keep the URL confidential. If it is ever compromised, use the Regenerate URL option in the webhook trigger properties to issue a new one. Note: regenerating the URL immediately breaks any existing integrations using the old URL.

What the external system sends

The external system must send an HTTP POST request to the webhook URL. The request must have a Content-Type of application/json or text/json, and the body must be a valid JSON object. No body is also acceptable if the workflow does not require incoming data.

Example of a minimal check-in payload the event app might send:

{
    "memberId": "12345",
    "eventCode": "CONF2026",
    "checkInTime": "2026-05-27T09:15:00",
    "sessionCode": "KEYNOTE"
}

Webhook response codes

When the external system calls the webhook, iHook responds immediately with one of the following status codes. The workflow itself runs asynchronously — the response does not wait for the workflow to complete.

By default, the response body includes a JSON object with the workflow run ID and the queue time. This can be suppressed by enabling the Omit Response Body option on the Webhook trigger if the calling system does not need it.

⚠️

IMPORTANT

The webhook does not support synchronous responses. The calling system cannot wait for the workflow to finish and receive the output data. The webhook only confirms that the request was queued successfully. If your integration requires a response with processed data, you will need a different approach.

Step-by-step: Building the iHook workflow

The following steps build the standard iHook pattern: Webhook trigger > JSON Schema Validation > Insert Activity. This three-action sequence is the direct equivalent of the legacy iTransfer webhook behavior and is the recommended starting point for most iHook integrations.

Step 1: Navigate to iWorkflow and create a blank workflow

Go to iDMS > iWorkflow from the Power Suite navigation to open the iWorkflow Dashboard. Click New and select Blank Workflow. The wizard templates do not include an iHook pattern, so starting from a blank workflow gives you direct control over the trigger and actions.

Step 2: Name the workflow

Give the workflow a clear, descriptive name that identifies both the source system and the action — for example, "Event Check-In > Insert Attendance Activity". This makes it easy to identify the workflow on the dashboard when you have multiple iHook integrations running.

Step 3: Set the trigger to Webhook

In the workflow editor, add a trigger and select Webhook. At this point, you will see a message indicating that the webhook URL has not been generated yet — it is created when you first save the workflow.

Configure the following optional Webhook trigger settings as needed:

• Metadata Output Property — If you want to capture HTTP request metadata (headers, remote host information) for use in later actions, enter a property name here. Leave blank if not needed.
• Return 202 Accepted — Check this if the calling system expects a 202 response instead of the default 200. This does not change behavior, only the response code.
• Omit Response Body — Check this to suppress the JSON response body if the external system does not need the run ID and queue time.

Save the workflow. After saving, return to the Webhook trigger's properties pane to find and copy the generated webhook URL. Share this URL with the team or vendor responsible for the external system that will be calling it.

Step 4: Add the JSON Schema Validation action

Add a JSON Schema Validation action as the first action in the sequence. This action checks that every incoming payload from the external system matches the expected structure before any data is written to iMIS. If the payload does not match the schema, the action fails, the workflow stops, and the webhook caller receives a descriptive error.

In the Schema field, paste a JSON Schema document that describes the expected payload. Use the draft-04 or draft-07 format. For the check-in scenario, a basic schema might look like this:

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "type": "object",
    "properties": {
        "memberId":    { "type": "string" },
        "eventCode":   { "type": "string" },
        "checkInTime": { "type": "string", "format": "date-time" },
        "sessionCode": { "type": "string" }
    },
    "required": ["memberId", "eventCode", "checkInTime"]
}

The required array lists fields that must be present in every payload. If any of these are missing, the validation fails and the caller receives a 400 Bad Request with details about what was wrong.

✅

TIP

If you need help building a JSON schema from a sample payload, online JSON Schema Generator tools can create a draft schema from a sample JSON object. Search for "JSON Schema Generator" to find one. Validate your schema with a JSON Schema parser tool before using it in production.

Step 5: Add the Insert Activity action

Add an Insert Activity action as the second step in the workflow. This action writes a new activity record into iMIS using the data that came in through the webhook payload.

Three fields are required by the Insert Activity action:

• ID — The iMIS member ID for the record the activity will be attached to.
• Activity Type — The iMIS activity type code for this record.
• Transaction Date — The date/time for the activity. If not provided, iWorkflow defaults to today's date.

To pull values from the incoming webhook payload, use iWorkflow's template syntax in the field values. The template engine uses Liquid-style double-curly-brace syntax. For example, to map the incoming memberId field to the ID field:

{{ input.memberId }}

To map the check-in time to the Transaction Date field:

{{ input.checkInTime }}

Some values can also be hard-coded as static text — for example, if the Activity Type is always the same regardless of what the external system sends, simply type the activity type code directly into the field without any template expression.

📘

NOTE

If you are migrating from legacy iTransfer webhooks, note that the old template syntax used $$propertyName$$. The new iWorkflow syntax is {{ propertyName }}. Update any field mappings accordingly when recreating a legacy webhook in iHook.

Step 6: (optional) Add Insert Panel Record

If your use case requires writing to a custom panel in iMIS rather than (or in addition to) an activity record, add an Insert Panel Record action. Select the target panel from the Panel Name dropdown, then map incoming payload fields to the panel's columns using the same template syntax.

Insert Panel Record has no required fields — any columns you populate are optional. Map only the fields that your integration needs to write.

Step 7: Save and activate

Review the workflow, save it, and confirm the workflow status is Active. The webhook endpoint is now live. The external system can begin sending POST requests to the webhook URL and iHook will process each one, validate the payload, and insert the corresponding record into iMIS.

Testing the iHook workflow

Unlike scheduled workflows that you can run against a subset of existing iMIS data, testing an iHook workflow requires sending actual HTTP POST requests to the webhook URL. A phased testing approach still applies — start simple, validate the results, then scale up.

Starting with a small dataset

Before coordinating with the external system vendor, test the webhook yourself using a REST API testing tool such as Postman or a similar HTTP client. This lets you control the exact payload and verify behavior without involving the external system.

To test with a small dataset:

1. Open Postman (or any HTTP client) and create a new POST request.
2. Set the URL to the webhook URL generated in Step 3.
3. Set Content-Type to application/json.
4. Paste a test JSON payload in the request body — use a known member ID from your iMIS test environment.
5. Send the request and confirm you receive a 200 (or 202) response.
6. Check the iWorkflow Dashboard to confirm a new run was created and succeeded.
7. Navigate to the member record in iMIS and verify the activity was inserted correctly.

Start with 3 to 5 test payloads that represent different scenarios: a valid payload, a payload with a missing required field, and a payload with a field in the wrong format. Each should behave predictably — valid payloads should succeed, invalid ones should return a 400 error and not create any records.

Validating the data

After each test send, validate both sides of the integration: confirm the workflow behaved correctly AND confirm the resulting data in iMIS is accurate.

Check the following for each test run:

• iWorkflow Dashboard — Confirm the run shows green (success) for valid payloads and red (failure/stopped) for intentionally invalid ones.
• Run log details — Open the specific run and review each action. For failed runs, the JSON Schema Validation action should show the specific validation error that caused the failure.
• iMIS record — For successful runs, navigate to the member record used in the payload and verify the activity was created with the correct Activity Type, Transaction Date, and any other mapped fields.
• No duplicate records — Confirm that sending the same payload twice creates two separate activity records (since Insert Activity always inserts, it does not deduplicate). If deduplication is needed, that logic must be handled upstream by the calling system or via a Gate action.

Scaling up gradually

Once individual payloads validate correctly, work with the external system vendor or developer to run a controlled batch of real test events — for example, have the check-in app send 10 to 20 check-in events from a test session. Verify each one appears correctly in iMIS before enabling the integration for live events.

Pay particular attention to timing and concurrency during this phase. Unlike scheduled workflows that process records in a predictable sequence, webhook workflows can be triggered many times in rapid succession if multiple check-ins happen simultaneously. Confirm iHook handles concurrent requests without issues before go-live.

✅

TIP

Use iMIS test accounts during all testing phases. Avoid using real member IDs during development to prevent creating spurious activity records that would need to be cleaned up manually.

Confirming the integration was successful

Because iHook workflows are triggered by external systems rather than staff actions, confirming success requires checking both the workflow run log and the resulting records in iMIS.

What to check after running

After each webhook-triggered run, verify the following:

• Run status on the iWorkflow Dashboard — Each inbound webhook call generates a workflow run. Green bars indicate success; red indicate failure.
• Action-level log — Click into any run to see each action's result. The JSON Schema Validation step will show either a pass or the specific schema violation. The Insert Activity step will show success or the error that prevented insertion.
• Response received by the caller — The external system should be logging the HTTP response code it received. A 200 or 202 means the payload was queued. Any 400 or 500 response means something went wrong at the webhook level before the workflow even ran.

Where to verify the data

Verifying the data means checking that the record was correctly created in iMIS, not just that the workflow run succeeded. A successful run means iHook attempted the insertion — you still need to confirm the data is right.

• Navigate directly to the affected member record in iMIS and review the Activities tab (or the relevant panel). Confirm the new record appears with the correct values.
• Run an IQA query to pull recently created activities of the relevant type, filtered to a date range that covers your test or production run. This gives a broader view across all affected records.
• Cross-reference with the external system's own logs. If the external system logged 50 check-ins and iMIS shows only 48 activity records, two payloads likely failed or were not sent correctly.

Understanding "partial" completion

Because each webhook call triggers its own independent workflow run, there is no concept of a single "partial" run in iHook the way there is in a batch iUpdate. Instead, you may see a mix of successful and failed runs in the dashboard.

A failed run means that specific payload was not processed. Common causes include:

• Schema validation failure — A required field was missing or had the wrong data type. The calling system sent a malformed payload.
• Invalid member ID — The ID value in the payload does not match any record in iMIS, causing the Insert Activity action to fail.
• Field constraint violation — A value provided for an activity field violates an iMIS business rule or data constraint.
• Server error — A transient connectivity or server issue caused the run to fail mid-execution.

The iWorkflow Dashboard color-coded bars make it easy to spot failed runs at a glance. Open any failed run to see the exact error message, which typically identifies the action that failed and why.

When to rerun vs. manually fix

Rerun if: The failure was caused by a transient server or connectivity error. From the iWorkflow Dashboard, locate the failed run and use the re-run option to attempt it again. If the underlying data was valid, the rerun should succeed.

Contact the external system if: The failure was a schema validation error (400) caused by a malformed payload from the calling system. The data was never written to iMIS for that run. Work with the vendor or developer to fix the payload format and resend the event, or manually create the missing record in iMIS if it is a one-off situation.

Manually fix the iMIS record if: The workflow ran successfully but the resulting record has incorrect data — for example, an activity was inserted with the wrong type or date because of a mapping error in the workflow. In this case, correct the record directly in iMIS and then fix the workflow mapping before the next event. Do not rerun the original workflow for that payload, as it would create a duplicate record.

Fix the workflow first, then rerun if: A configuration error in the Insert Activity or Insert Panel Record action is causing consistent failures. Fix the mapping or field configuration in the workflow editor, verify the fix with a test payload, and then decide whether failed runs from before the fix need to be reprocessed by the external system.

iImport, iUpdate, and iHook: Choosing the right tool

The iDMS Power Suite offers several ways to get data into iMIS. iHook is the right answer for some situations and the wrong one for others. Understanding how iHook compares to iImport and iUpdate helps you choose the appropriate tool for each integration scenario.

iImport

iImport is a file-driven tool: you upload a spreadsheet (Excel or CSV) and iDMS processes it to insert new records, update existing ones, or both. Matching logic determines whether a row in the spreadsheet corresponds to an existing iMIS record or should be treated as new.

iImport is the right choice when data arrives as a file from an external system — such as an event registration export, a spreadsheet from a partner organization, or a data migration during implementation. It is a batch tool: you run it when you have the file ready, not in real time.

iUpdate

iUpdate uses an IQA query to select records that already exist in iMIS, then applies changes to those records based on configured field mappings. The source is always iMIS data itself — iUpdate cannot bring in data from outside the system.

iUpdate is the right choice for logic-driven operations on existing iMIS data: updating member types, populating calculated fields, clearing flags, or creating activities for records that meet certain criteria. It pairs naturally with iWorkflow for scheduled automation.

iHook

iHook is an event-driven, real-time integration tool. An external system sends a JSON payload to a webhook URL, and iHook immediately inserts a new activity or panel record into iMIS. No file, no batch window, no staff action required.

iHook is the right choice when the trigger is external (something happens outside iMIS), the timing is real-time (the record needs to exist in iMIS immediately), and the operation is an insert (not an update to an existing record).

Side-by-side comparison

Expected outcome

After completing this tutorial, you will have a live iHook webhook integration that receives data from an external system and automatically inserts records into iMIS in real time. Here is what to expect once the workflow is active and the external system is sending data:

• Each check-in (or equivalent event) in the external system triggers a POST to the webhook URL and creates a new workflow run.
• The JSON Schema Validation action confirms the payload is well-formed before any data touches iMIS. Malformed payloads are rejected with a 400 response and logged in the run history.
• Valid payloads immediately result in new activity records in iMIS — no staff intervention, no end-of-day import, no delay.
• The iWorkflow Dashboard provides a real-time view of every inbound call: how many succeeded, how many failed, and the details of each.
• The external system receives immediate HTTP response confirmation for every call, so it knows whether the payload was accepted.

For the conference check-in scenario from this tutorial: from the moment the workflow is live, every attendee who checks in at the event app immediately has an attendance activity record in iMIS. Staff can query attendance in real time rather than waiting for an end-of-day file import, and the manual export/import process is permanently eliminated.