Trava
Docs
Trava.co
Home
Additional
Other elements
Action is enabled
Action not available
Exists only if PNR accessibility is enabled

Other elements

Action namePNR processingPNR pricingPNR redirectorTicket processingEMD processing
1A1S1G
1A1S1G
1A1S1G
1A1S1G
1A1S1G
Delete all ticketing requests
HTTP Notification
Process by another scheme
Remove tags
Send e-mail
Set tags
Stop processing in another scheme

Delete all ticketing requests

Applicable to GDS/Schemes

Amadeus
Sabre
Galileo

Overview

Removes selected ticketing requests from the current processing instance.

How it works

The Delete ticketing request step removes ticketing requests previously assigned to the current processing instance.

Use this step to cancel ticketing requests that are no longer applicable. Removing a ticketing request causes the Ticketing request exist condition to evaluate as false. This prevents the current processing instance from being routed to workflow paths that depend on this condition, unless another ticketing request is assigned later.

Although there is only one ticketing request marker, it can be assigned from different sources. This step allows you to remove ticketing requests created by selected sources only.

Settings

Specifies which ticketing request sources to remove.

Multiple sources can be selected:

  • Manual – Removes ticketing requests assigned manually from the Monitoring Panel.
  • Evaluation threshold – Removes ticketing requests assigned automatically by the Start step when a Fare increase rule with the Issue tickets option enabled is triggered.
  • Scheme action – Removes ticketing requests assigned automatically by any other workflow components.

HTTP Notification

Applicable to GDS/Schemes

Amadeus
Sabre
Galileo

Overview

Used to exchange data between Trava and external web applications via HTTP.

Description

The HTTP Notification step enables integration between Trava and external web applications by sending HTTP requests during scheme execution.

It allows you to send custom requests containing dynamic data from the processed PNR or ticket and optionally retrieve data from the HTTP response for use in subsequent workflow components.

The step sends an HTTP request using the configured method (POST, PUT, or PATCH) to the specified endpoint.

The request payload can consist of:

  • custom text or JSON;
  • one or more system variables;
  • or a combination of both.

System variables are automatically populated with values from the processed PNR or ticket.

If configured, the response returned by the server can be parsed and stored in custom variables. These variables can then be used by subsequent workflow components, such as conditions, remarks, or additional HTTP Notification steps.

Settings

  1. Use template

    Applies a pre-saved configuration instead of manual setup. Useful when multiple schemes use HTTP Notification components with identical configurations.

    ℹ️

    Tip

    Changing a shared template automatically updates all components using that template. For details on managing templates, see the Templates section.
    ⚠️

    Warning

    Applying a template overwrites any settings entered manually in this step.
  2. Endpoint url

    Specifies the destination URL.

    Supports:

    • full path to an external HTTP/HTTPS resource, including the protocol (for example, https://);
    • relative path when using the Trava API.
  3. Authentication method

    Specifies the authentication method used when sending the HTTP request.

    Supports:

    • Anonymous – no authentication.
    • Basic authentication – uses a user name and password.
    • Bearer token – uses a token obtained from an external service.

    Selecting Basic authentication or Bearer token displays the corresponding additional fields.

    ⚠️

    Warning

    The selected authentication method and provided credentials must match the requirements of the receiving API.
  4. Message

    Specifies the content of the message to be sent.

    Supports:

    • plain text, or
    • structured data (for example, JSON).

    Can include custom variables to personalize the message content.

  5. Variables

    Selects one or more variables whose values are sent to the external application.

    If at least one variable is selected, the system automatically generates the HTTP request body as JSON, where each variable name is used as a key and the value is populated from the processed PNR.

    ℹ️

    Tip

    If Message is also filled in, its content is added to the generated JSON under the notificationMessage property.
  6. HTTP custom headers

    Allows adding custom HTTP headers to be sent with the request.

  7. HTTP method

    Specifies the HTTP method used to send the request.

    Supports:

    • POST (default);
    • PUT;
    • PATCH.
  8. Send as plain text

    Specifies the format of the data sent in the HTTP request body.

    • If enabled, the data is sent as plain text.
    • If disabled, the data is sent in JSON format.
    ℹ️

    Tip

    When custom variables are used in plain text mode, only the value of one variable is sent.
  9. Number of notification attempts for erroneous responses

    Specifies the maximum number of retry attempts before the system stops trying and raises an error.

  10. Save response to custom variables

    Allows capturing the server's response and storing a value from it in a custom variable. The stored value can be used as input for subsequent components or conditions in the workflow.

  11. Preview

    Allows testing the payload before scheme activation. Enter a specific PNR or select one from the list to view the exact JSON payload the system generates for that PNR.

Examples

Example 1

Sending a custom JSON message to an external web application (Postman) using a POST request.

Configured options:

  1. Endpoint URL: https://postman-echo.com/post
  2. Message: {"sample_payload": "test"}

Payload:

{"sample_payload": "test"}

Response:

{
  "args": {},
  "data": {
    "samplePayload": "test"
  },
  "files": {},
  "form": {},
  "headers": {
    "host": "postman-echo.com",
    "contentLength": "26",
    "accept": "application/json",
    "contentType": "application/json",
    "traceparent": "00-a00bfb6096f35ea86ff902f0dd985ad9-e2cbcfb037f52ef6-01",
    "acceptEncoding": "gzip, br",
    "xForwardedProto": "https"
  },
  "json": {
    "samplePayload": "test"
  },
  "url": "https://postman-echo.com/post"
}

Example 2

Sending JSON message with the values of the selected variables to an external web application (Postman) using POST request.

Configured options:

  1. Endpoint URL: https://postman-echo.com/post
  2. Selected variables

Payload:

{
  "PNR": "HZJDOV",
  "issuingCarriersCodes": ["AY"],
  "destinationCityCode": "OSA"
}

Response:

{
  "args": {},
  "data": {
    "PNR": "HZJDOV",
    "issuingCarriersCodes": ["AY"],
    "destinationCityCode": "OSA"
  },
  "files": {},
  "form": {},
  "headers": {
    "host": "postman-echo.com",
    "contentLength": "153",
    "accept": "application/json",
    "contentType": "application/json",
    "traceparent": "00-af825e9bcd629cf2c3a1cc705f9111cc-8fd8fed62f3871e1-01",
    "acceptEncoding": "gzip, br",
    "xForwardedProto": "https"
  },
  "json": {
    "notificationMessage": "{\"my_parameter\": \"value\"}",
    "pNR": "HZJDOV",
    "issuingCarriersCodes": ["AY"],
    "destinationCityCode": "OSA"
  },
  "url": "https://postman-echo.com/post"
}

Example 3

Sending a message together with variables.

In this scenario, the component is used to send a JSON consisting of the value of the Message field and the values of the selected variables to an external web application using a POST request.

Payload:

{
  "NotificationMessage": "{\"my_parameter\": \"value\"}",
  "PNR": "WYDYES",
  "IssuingCarriersCodes": ["AI"],
  "DestinationCityCode": "KTM"
}

Response:

{
  "args": {},
  "data": {
    "notificationMessage": "{\"my_parameter\": \"value\"}",
    "pNR": "HZJDOV",
    "issuingCarriersCodes": ["AY"],
    "destinationCityCode": "OSA"
  },
  "files": {},
  "form": {},
  "headers": {
    "host": "postman-echo.com",
    "contentLength": "153",
    "accept": "application/json",
    "contentType": "application/json",
    "traceparent": "00-af825e9bcd629cf2c3a1cc705f9111cc-8fd8fed62f3871e1-01",
    "acceptEncoding": "gzip, br",
    "xForwardedProto": "https"
  },
  "json": {
    "notificationMessage": "{\"my_parameter\": \"value\"}",
    "pNR": "HZJDOV",
    "issuingCarriersCodes": ["AY"],
    "destinationCityCode": "OSA"
  },
  "url": "https://postman-echo.com/post"
}

Note

Troubleshooting

If an issue occurs with the HTTP Notification component, take the following steps before submitting a bug report:

  1. Review the processing session log. Errors sending a request appear in the log with the status, response message, response content, endpoint URL, and variables used.
  2. Verify the error source. Server errors such as 500, 503, or 404 indicate a problem with the external application, not with Trava.
  3. Confirm the outgoing request. If the request is formatted correctly and includes all required values, the request left the system as intended. Investigate the issue in the receiving service or your own infrastructure.

Process by another scheme

Applicable to GDS/Schemes

Amadeus
Sabre
Galileo

Overview

Redirects a PNR, ticket, or EMD to be processed by another scheme.

How it works

The Process by another scheme step links processing of an object across multiple schemes. The system passes the object to the selected scheme and starts its processing, either by creating a new instance or resuming an existing one. The timing of the launch and the resume behavior are controlled by the step's settings.

ℹ️

Tip

If processing of the object (PNR, ticket, or EMD) in the destination scheme was stopped by a Pause step, resumption continues from that step.

Settings

1. Select object to process

Defines the object to process in another scheme:

  • PNRs or Related PNRs – for schemes that process bookings.
  • Tickets – for ticketing schemes.
  • EMD – for schemes that process EMDs.

2. Select destination scheme

Defines the scheme or schemes to which the object is passed for processing. Available schemes appear in a drop-down list.

ℹ️

Tip

Only active schemes configured for the same GDS as the current scheme are available for selection, excluding the current scheme itself.

3. Start processing immediately

Allows resuming processing in the destination scheme without waiting for the scheduled time, when the instance status is Paused.

If disabled, the destination scheme does not intervene and processing runs on schedule. In this case, the processing history logs the following warning:

Instance for processing [Object ID] under schema "Schema name" already exists but could not be started.
Reason: The next processing time is already scheduled and there is no requirement for an immediate processing start.
ℹ️

Tip

  • For instances with the status Completed, a restart occurs only if setting 4 is enabled.
  • The actual start still respects the minimum delay defined in setting 5.

4. Restart completed processing

Allows restarting processing in the destination scheme for objects that already completed processing there and currently have the status Completed.

If disabled, an incoming object with the status Completed is not restarted. The processing history logs the following record:

Instance for processing [Object ID] under schema "Schema name" already exists but could not be started.
Reason: Processing has already completed and there is no requirement to restart.

5. Delay before start

Defines the delay before the destination scheme starts processing, allowing the current scheme to finish processing. Default value: 15 seconds.

Notes

Often used with

  • The active instance is processed in a different schema (condition) – checks whether the PNR has already been processed by another scheme.
  • Stop processing by another scheme (action) – stops processing in one or several schemes.

Remove tags

Applicable to GDS/Schemes

Amadeus
Sabre
Galileo

Send e-mail

Applicable to GDS/Schemes

Amadeus
Sabre
Galileo

Set tags

Applicable to GDS/Schemes

Amadeus
Sabre
Galileo

Stop processing in another scheme

Applicable to GDS/Schemes

Amadeus
Sabre
Galileo

Overview

Stops processing in one or more selected schemes.

How it works

When triggered, the system sets the target scheme's status to Completed.

  • If a next run was scheduled for the target scheme, it does not execute.
  • If processing in the target scheme was paused at a Pause step, the steps that follow Pause do not execute.

Settings

[image]

  1. Schemes (required) – Specifies the target scheme(s) where processing stops. Accepts one or more schemes.
ℹ Note: Schemes with a Draft status (never activated) do not appear in the list. Schemes marked with a 🚫 icon are inactive; the icon helps identify their state directly in the list.

Often used with

  • Process by another scheme – has the opposite behavior: triggers processing in another scheme rather than stopping it.
  • The active instance is processed in a different schema (condition) – checks whether the PNR has already been processed by another scheme.