> For the complete documentation index, see [llms.txt](https://partner-docs.covergenius.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://partner-docs.covergenius.com/xcover-elements/client-integration/element-signals/set-signal.md). # Set signal This page details the requirements to integrate the set signal which is used to request the offers and display aligned currency formatting and order total values across the panel. ## Using `set` signal The `set` signal is how a partner 1) creates an offer request for a customer and 2) formats the displayed currency in the element. {% hint style="info" %} For existing XCover partners, this replaces the create offer API request, with a similar field structure. {% endhint %} Call `signalLayer.push()` with `set` as the value for the `signal` property, add `onSet` and `data` as in the following example: 
/* Travel xce-protection-offer example */
window.signalLayer.push({
  signal: 'set',
  element: 'xce-protection-offer',
  onSet: async (req) => {
    try {
      const response = await req
      if (!response) throw new Error('Empty response');
      // your disable checkout logic here..
    } catch (err) {
      console.error('XCE Request Error: ', err);
    }
  },
  data: {
    offer_request: {
      schema: 'demo-partner-travel:1',
      customer:{
        currency: 'AUD',
        country: 'AU',
        language: 'en',
      },
      context: {
        total_tickets_price: 344,
        departure_country: 'AU',
        destination_country: 'US',
        is_return: false,
        number_of_children: 0,
        number_of_adults: 1,
        number_of_infants: 0,
        trip_start_date: '2026-05-19T19:03:36.671Z',
        trip_end_date: '2026-05-19T19:02:21.444Z',
        flights: [
          {
            legs: [
              {
                departure_datetime: '2025-09-19T18:59:13.958Z',
                arrival_datetime: '2025-09-19T18:59:13.958Z',
                flight_number: 'SK1530',
                marketing_airline_iata_code: 'SK',
                marketing_airline_icao_code: 'SAS',
                operating_airline_iata_code: 'SK',
                operating_airline_icao_code: 'SAS',
                departure_airport: 'SYD',
                arrival_airport: 'JFK',
                departure_country: 'AU',
                arrival_country: 'US',
              },
            ],
            departure_datetime: '2025-09-19T18:59:13.958Z',
            arrival_datetime: '2025-09-19T18:59:13.958Z',
            departure_country: 'AU',
            departure_city: 'SYD',
            arrival_city: 'JFK',
          },
        ],
      },
    },
    currency_config: {
      trailingZeroDisplay: 'stripIfInteger'
    }
  }
});
### onSet The `onSet` property is a Promise function that will resolve with the quote response if successful, and the `data.offer_request` property is the create offer request body. {% hint style="warning" %} In order to get the offer response data for **confirm offer request** make sure to store the response from the `onSet` promise. The resolved value contains the needed fields for **Confirm Offer** request, including the BrightWrite details object. {% endhint %} {% hint style="info" %} See [Create Offer request fields](/xcover-elements/client-integration-examples/requests-and-responses.md) for a simplified reference to the data object {% endhint %} `onSet` may be invoked more than once * Every `set` signal you push receives its own fresh promise, including integrations that reuse a single `onSet` handler function. * Elements with in-element update actions (for example a coverage date change) invoke `onSet` again when the customer updates the offer. That promise resolves with the updated offer on success, or with the unchanged previous offer if the update fails; update promises never reject. Treat each resolution as the current offer, and store it for the Confirm Offer request. {% hint style="info" %} See [Checkout Enablement](/xcover-elements/client-integration/checkout-enablement.md) for the rejection codes and recommended handling. {% endhint %} ### timeout `timeout` is an optional circuit breaker on the Set signal's offers API call. If the API does not respond within the configured duration, Elements aborts the in-flight fetch and rejects the partner's `onSet` promise. Partners opt in by adding a `timeout` property (milliseconds) to their Set signal push: ```javascript window.signalLayer.push({ signal: 'Set', element: 'xce-protection-offer', timeout: 2000, data: { offer_request: { ... } }, onSet: (promise) => promise.catch((err) => { /* handle timeout or other errors */ }) }); ``` When `timeout` is omitted or `undefined`, no timeout is enforced. Valid range: **1001–10 000ms**. {% hint style="info" %} Any failed check logs a `console.warn` that includes the element's `tagName` i.e. "\[CG] The "timeout" value for \ must be greater than 1000ms." {% endhint %} #### Error shape A timeout abort follows the same rejection path as any other API failure: * `onSet` rejects with an `Error` whose `message` is `XCE_OFFER_REQUEST_FAILED` and whose `cause` is the `AbortError` from the aborted fetch. * This is identical to how network failures and server errors surface. Handle timeouts with their existing `onSet` error path. * The `AbortError` cause is distinguishable from other failures: its `message` contains the timeout duration and element tag name. * i.e. "Exceeded API timeout of 3000ms. Element \" --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://partner-docs.covergenius.com/xcover-elements/client-integration/element-signals/set-signal.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.