AppVisit

Overview

Technical name: AppVisit · ActionType: 21

Use AppVisit for an interaction with an application. The AppVisit ActionKey identifies the provisioned application context.

Open in REST Explorer

Requirements and Inputs

Input	Applicability
ActionKeyToken	Required: an ActionKey provisioned for AppVisit (21) and the application context.
User identity and destination context	Use the identity and destination fields agreed for the provisioned application.
Session ID (403), timestamp (400), integration user ID (304)	Optional/conditional correlation context according to the integration.

All requests use the shared User Action endpoint. Provisioning determines required identity and destination signals. Optional fields are defined in Action Fields.

Request Examples

Replace YOUR_ACTION_KEY with the correctly provisioned token. The first example shows the basic shape for this context; add all signals required by your integration. These examples do not provision an action or guarantee a production-valid identity.

Basic request

{
  "ActionKeyToken": "YOUR_ACTION_KEY",
  "Values": [
    {
      "SignalValueType": 403,
      "DataType": 0,
      "UnitType": 0,
      "Value": "example-app-001",
      "OptionIDs": {}
    },
    {
      "SignalValueType": 400,
      "DataType": 0,
      "UnitType": 0,
      "Value": "2026-10-21T12:00:00Z",
      "OptionIDs": {}
    }
  ]
}

With additional context

{
  "ActionKeyToken": "YOUR_ACTION_KEY",
  "Values": [
    {
      "SignalValueType": 403,
      "DataType": 0,
      "UnitType": 0,
      "Value": "example-app-001",
      "OptionIDs": {}
    },
    {
      "SignalValueType": 400,
      "DataType": 0,
      "UnitType": 0,
      "Value": "2026-10-21T12:00:00Z",
      "OptionIDs": {}
    },
    {
      "SignalValueType": 304,
      "DataType": 0,
      "UnitType": 0,
      "Value": "example-app-user",
      "OptionIDs": {}
    },
    {
      "SignalValueType": 47,
      "DataType": 0,
      "UnitType": 0,
      "Value": "buyer@example.com",
      "OptionIDs": {}
    }
  ]
}

Expected Result

The shared response may contain Result, correlation identifiers, and configured signals. Read the returned values according to the configured model and product. Do not assume every action returns an IH Score or the same response fields.

See the response contract and API Results and Errors. An HTTP response or accepted event alone does not prove downstream delivery or a business outcome.

Processing and Feedback

The examples illustrate the shared envelope and session context. Add the identity/destination signals required by the provisioned application before production use. Apply the result through your application logic, using the timeout and default handling agreed for the integration.

When reporting an observed outcome, use Disposition (19) and its correlation rules. Never reuse a different ActionType ActionKey as an outcome key.

Delivery and Troubleshooting

This guide documents API submission. Use only other delivery methods explicitly provisioned for your integration. If a request fails, verify the API key, the exact ActionKey type, required signal values, and the actual HTTP and API result. Review retry/correlation behavior before resubmitting after a timeout.