User journey API

Send synthetic request results to xrelia to monitor the availability and performance of critical user journeys and application workflows.

Synthetic requests allow you to verify that your application is working from a user’s perspective, rather than only checking whether individual services are available.

Endpoint

POST https://api.xrelia.com/v1/user-journey

The request must include a valid X-API-Key header. See Authentication section for details.

Request

The request body must be a JSON object containing the target platform, service instance, and one or more synthetic request results.

{
  "platformId": "PLATFORM_ID",
  "instanceId": "INSTANCE_ID",
  "syntheticRequestResults": [
    {
      "id": "SYNTHETIC_REQUEST_ID",
      "ts": 1785513412,
      "sts": 0,
      "ms": 280
    },
    {
      "id": "SYNTHETIC_REQUEST_ID",
      "ts": 1785513412,
      "sts": 100,
      "ms": 320
    }
  ]
}

Request fields

Field	Type	Required	Description
platformId	string	Yes	ID of the Platform receiving the synthetic request results. Obtain this from the xrelia console.
instanceId	string	Yes	ID of the Service Instance associated with the user journey. Obtain this from the xrelia console.
syntheticRequestResults	array	Yes	Collection of synthetic request results to submit.
syntheticRequestResults[].id	string	Yes	ID of the synthetic request. Obtain this ID from the xrelia console.
syntheticRequestResults[].ts	integer	Yes	Unix timestamp indicating when the synthetic request was performed.
syntheticRequestResults[].sts	integer	Yes	Request status. 0 means the request failed and 100 means it succeeded.
syntheticRequestResults[].ms	number	No	Request latency in milliseconds. Can be omitted when the request fails and no meaningful latency is available.

Synthetic Request ID

Each synthetic request configured in xrelia has a unique ID. The ID identifies the specific step or operation being monitored.

Use the ID assigned to the synthetic request in the xrelia console when submitting results.

Timestamp

The ts field specifies when the synthetic request was performed, rather than when the result was submitted to xrelia.

The value must be a Unix timestamp expressed in seconds.

For example:

1785513412

Status

The sts field indicates whether the synthetic request succeeded.

xrelia currently uses a binary status model:

Value	Meaning
0	Request failed
100	Request succeeded

Intermediate status values are not currently supported.

Latency

The optional ms field contains the synthetic request response time in milliseconds.

For a successful request, include the measured latency whenever possible:

{
  "id": "SYNTHETIC_REQUEST_ID",
  "ts": 1785513412,
  "sts": 100,
  "ms": 320
}

When the request fails and no meaningful latency measurement is available, ms can be omitted:

{
  "id": "SYNTHETIC_REQUEST_ID",
  "ts": 1785513412,
  "sts": 0
}

Response

A successful request returns:

200 OK

If the request cannot be processed, xrelia returns an appropriate HTTP error status together with a descriptive error message.

A 207 Multi-Status response is returned when a request is only partially successful—for example, when some synthetic request results are accepted while others fail validation.

See API Overview for general response and error handling.

Example

curl -X POST "https://api.xrelia.com/v1/user-journey" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_API_KEY" \
  -d '{
    "platformId": "PLATFORM_ID",
    "instanceId": "INSTANCE_ID",
    "syntheticRequestResults": [
      {
        "id": "LOGIN_REQUEST_ID",
        "ts": 1785513412,
        "sts": 100,
        "ms": 245
      },
      {
        "id": "CHECKOUT_REQUEST_ID",
        "ts": 1785513412,
        "sts": 0
      }
    ]
  }'

Synthetic request results become part of the service instance’s reliability data, allowing xrelia to evaluate application availability and user-facing performance as part of its overall health and confidence analysis.