> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nelieo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ActionResponse: POST /action Response Body Reference

> Reference for the ActionResponse object returned by POST /action — success status, return value, execution latency, and optional VerificationResult.

Every call to `POST /action` returns an `ActionResponse` object. It tells you whether the action was dispatched, whether any post-action verification expression was satisfied, how long the full round-trip took, and — when the action produces a return value — what the runtime returned. For actions dispatched with `verify: true`, the response also embeds a [`VerificationResult`](/models/verification) that captures the expression evaluated, the computed value, and whether it was satisfied within the timeout.

<ResponseField name="success" type="boolean" required>
  `true` when the action was dispatched **and** either no verification was requested or the `verify_expression` evaluated to `true` within `verify_timeout_ms`. `false` when the action failed to dispatch, the expression never became true before the timeout, or the probe returned an error during post-action polling.

  When `success` is `false` due to a verification timeout, the HTTP status is `422 Unprocessable Entity`. For dispatch failures (pre-flight errors, wrong PID, unknown action name) the HTTP status is `400` or `404`.
</ResponseField>

<ResponseField name="result" type="any">
  The raw return value of the action as reported by the runtime. For V8 actions this is the JavaScript return value serialized to JSON. For JVM and CLR actions this is the method return value converted from its native type. For actions that return nothing (void functions or UI interactions) this field is `null`.
</ResponseField>

<ResponseField name="latency_ms" type="integer" required>
  Total wall-clock time in milliseconds from the moment NSP received the request to when it sent the response. For requests with `verify: true`, this includes all post-action polling time. For requests without verification, it reflects only dispatch latency.
</ResponseField>

<ResponseField name="action_name" type="string" required>
  The name of the action that was invoked, echoed back from the request. Useful for logging and for correlating responses when you fire multiple concurrent requests.
</ResponseField>

<ResponseField name="pid" type="integer" required>
  The OS process ID of the application against which the action was executed, echoed back from the request.
</ResponseField>

<ResponseField name="executed_at" type="string" required>
  ISO 8601 UTC timestamp of when the action was dispatched to the runtime, for example `"2026-07-20T13:00:00.312Z"`. Note that `executed_at` reflects the dispatch moment — if `verify: true`, additional time elapses after this for post-action polling before the response is returned.
</ResponseField>

<ResponseField name="verification" type="object">
  Present and populated when `verify: true` was set in the request. Contains the full post-action verification result. `null` when no verification was requested.

  <Expandable title="VerificationResult fields">
    <ResponseField name="satisfied" type="boolean" required>
      `true` if `verify_expression` evaluated to `true` within `verify_timeout_ms`. `false` if the timeout was reached without the expression becoming true.
    </ResponseField>

    <ResponseField name="actual_value" type="any" required>
      The computed value of `verify_expression` at the final poll cycle. When `satisfied: true` this is the truthy value that stopped polling (typically `true`). When `satisfied: false` this is whatever the expression last evaluated to (typically `false` or a number that did not meet a comparison threshold).
    </ResponseField>

    <ResponseField name="expression" type="string" required>
      The exact `verify_expression` string that was evaluated, echoed back from the request. Useful for logging and correlating verification outcomes with the original request.
    </ResponseField>

    <ResponseField name="evaluated_at" type="string" required>
      ISO 8601 UTC timestamp of when the final evaluation occurred — either the cycle that satisfied the expression or the last cycle before the timeout.
    </ResponseField>

    <ResponseField name="latency_ms" type="integer" required>
      Total time in milliseconds spent in the post-action polling loop, from after the `post_action_wait_ms` settling delay through to the final poll cycle.
    </ResponseField>
  </Expandable>
</ResponseField>

***

## JSON Example — Success with Verification

```json theme={null}
{
  "success": true,
  "result": true,
  "latency_ms": 312,
  "action_name": "send_reply",
  "pid": 12847,
  "executed_at": "2026-07-20T13:00:00.000Z",
  "verification": {
    "satisfied": true,
    "actual_value": true,
    "expression": "inbox.sent_count > 0",
    "evaluated_at": "2026-07-20T13:00:00.280Z",
    "latency_ms": 280
  }
}
```

## JSON Example — Success without Verification

```json theme={null}
{
  "success": true,
  "result": true,
  "latency_ms": 85,
  "action_name": "archive",
  "pid": 12847,
  "executed_at": "2026-07-20T13:05:22.100Z",
  "verification": null
}
```

## JSON Example — Failure (Verification Timeout)

When NSP dispatches the action but the `verify_expression` never becomes true before the timeout, it returns `HTTP 422` with `success: false`:

```json theme={null}
{
  "success": false,
  "result": null,
  "latency_ms": 5312,
  "action_name": "send_reply",
  "pid": 12847,
  "executed_at": "2026-07-20T13:10:00.000Z",
  "verification": {
    "satisfied": false,
    "actual_value": false,
    "expression": "inbox.sent_count > 0",
    "evaluated_at": "2026-07-20T13:10:05.000Z",
    "latency_ms": 5000
  }
}
```

A `422` response means the action was dispatched but the expected state change was not observed. Treat this as an indeterminate outcome — the action may have succeeded on the application side but the state probe did not confirm it within the timeout window. You should inspect the current state (via `GET /state`) and potentially increase `verify_timeout_ms` for slow operations before retrying.