Package markets.alpaca.client.openapi.broker.api

Class EventsApi

java.lang.Object
markets.alpaca.client.openapi.broker.api.EventsApi
public class EventsApi extends Object
Generated client for EventsApi operations.

This class is generated from the configured OpenAPI spec. Operation method Javadocs include OAS summaries, descriptions, parameters, return types, response details, and external documentation links when present in the spec.

Operations

  • getV1EventsNta: Subscribe to Non-Trading Activities Events (SSE)
  • subscribeToActivitiesSSE: Subscribe to Activity Events (SSE)
  • subscribeToAdminActionSSE: Subscribe to Admin Action Events (SSE)
  • subscribeToFundingStatusSSE: Subscribe to Funding Status Events (SSE)
  • subscribeToIPOEventsSSE: Subscribe to IPO Events (SSE)
  • subscribeToJournalStatusSSE: Subscribe to Journal Events (SSE) (Legacy)
  • subscribeToJournalStatusV2SSE: Subscribe to Journal Events (SSE)
  • subscribeToSystemEventV2SSE: Subscribe to System Events (SSE)
  • subscribeToTradeSSE: Subscribe to Trade Events (SSE) (Legacy)
  • subscribeToTradeV2SSE: Subscribe to Trade Events (SSE)
  • subscribeToTransferStatusSSE: Subscribe to Transfer Events (SSE) (Legacy)
  • suscribeToAccountStatusSSE: Subscribe to Account Status Events (SSE)

  • Constructor Details

    • EventsApi

      public EventsApi()

    • EventsApi

      public EventsApi(ApiClient apiClient)

  • Method Details

    • getApiClient

      public ApiClient getApiClient()

    • setApiClient

      public void setApiClient(ApiClient apiClient)

    • getHostIndex

      public int getHostIndex()

    • setHostIndex

      public void setHostIndex(int hostIndex)

    • getCustomBaseUrl

      public String getCustomBaseUrl()

    • setCustomBaseUrl

      public void setCustomBaseUrl(String customBaseUrl)

    • getV1EventsNtaCall

      public okhttp3.Call getV1EventsNtaCall(@Nullable String id, @Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid, @Nullable Boolean includePreprocessing, @Nullable UUID groupId, ApiCallback _callback) throws ApiException
      Build call for getV1EventsNta
      Parameters:
      id - (optional)
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      includePreprocessing - (optional)
      groupId - ID used to link activities who share a sibling relationship (optional)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 OK -

    • getV1EventsNta

      public NonTradeActivityEvent getV1EventsNta(@Nullable String id, @Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid, @Nullable Boolean includePreprocessing, @Nullable UUID groupId) throws ApiException
      Subscribe to Non-Trading Activities Events (SSE) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to non-trading activities updates as they get processed by our backoffice, for both end-user and firm accounts. Historical events are streamed immediately if queried, and updates are pushed as events occur. You can listen to when NTAs are pushed such as CSDs, JNLC (journals) or FEEs. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since_ulid` required if `until_ulid` specified - `since`, `since_id` or `since_ulid` can't be used at the same time Behavior: - if `since`, `since_id` or `since_ulid` not specified this will not return any historic data - if `until`, `until_id` or `until_ulid` reached stream will end (status 200)'
      Parameters:
      id - (optional)
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      includePreprocessing - (optional)
      groupId - ID used to link activities who share a sibling relationship (optional)
      Returns:
      NonTradeActivityEvent
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 OK -

    • getV1EventsNtaWithHttpInfo

      public ApiResponse<NonTradeActivityEvent> getV1EventsNtaWithHttpInfo(@Nullable String id, @Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid, @Nullable Boolean includePreprocessing, @Nullable UUID groupId) throws ApiException
      Subscribe to Non-Trading Activities Events (SSE) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to non-trading activities updates as they get processed by our backoffice, for both end-user and firm accounts. Historical events are streamed immediately if queried, and updates are pushed as events occur. You can listen to when NTAs are pushed such as CSDs, JNLC (journals) or FEEs. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since_ulid` required if `until_ulid` specified - `since`, `since_id` or `since_ulid` can't be used at the same time Behavior: - if `since`, `since_id` or `since_ulid` not specified this will not return any historic data - if `until`, `until_id` or `until_ulid` reached stream will end (status 200)'
      Parameters:
      id - (optional)
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      includePreprocessing - (optional)
      groupId - ID used to link activities who share a sibling relationship (optional)
      Returns:
      ApiResponse<NonTradeActivityEvent>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 OK -

    • getV1EventsNtaAsync

      public okhttp3.Call getV1EventsNtaAsync(@Nullable String id, @Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid, @Nullable Boolean includePreprocessing, @Nullable UUID groupId, ApiCallback<NonTradeActivityEvent> _callback) throws ApiException
      Subscribe to Non-Trading Activities Events (SSE) (asynchronously) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to non-trading activities updates as they get processed by our backoffice, for both end-user and firm accounts. Historical events are streamed immediately if queried, and updates are pushed as events occur. You can listen to when NTAs are pushed such as CSDs, JNLC (journals) or FEEs. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since_ulid` required if `until_ulid` specified - `since`, `since_id` or `since_ulid` can't be used at the same time Behavior: - if `since`, `since_id` or `since_ulid` not specified this will not return any historic data - if `until`, `until_id` or `until_ulid` reached stream will end (status 200)'
      Parameters:
      id - (optional)
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      includePreprocessing - (optional)
      groupId - ID used to link activities who share a sibling relationship (optional)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 OK -

    • subscribeToActivitiesSSECall

      public okhttp3.Call subscribeToActivitiesSSECall(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId, ApiCallback _callback) throws ApiException
      Build call for subscribeToActivitiesSSE
      Parameters:
      since - Format: RFC3339 or YYYY-MM-DD (optional)
      until - Format: RFC3339 or YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToActivitiesSSE

      public List<ActivityEventV2> subscribeToActivitiesSSE(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId) throws ApiException
      Subscribe to Activity Events (SSE) The Events API sends the real-time events and provides historical queries with SSE (Server Sent Events). This endpoint streams events on account activities. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query parameter rules: - If `until` is specified, `since` is required. - If `until_id` is specified, `since_id` is required. - You cannot use `since` and `since_id` together. Behavior: - If `since` or `since_id` is not specified, this will not return any historic data. - If `until` or `until_id` is specified, stream will end at the specified point with status 200. --- Warning: Currently, OAS-3 does not fully support responses from an SSE API. In case the client code is generated from this OAS spec, please do not specify `since` and `until`, as the generated client may hang forever waiting for the response to end. If you require the streaming capabilities, we recommend not using the generated clients for this specific endpoint until the OAS-3 standards define how to represent this behavior. --- ### Comment messages According to the SSE specification, any line that starts with a colon is a comment which does not contain data. It is typically a free text that does not follow any data schema. A few examples mentioned below for comment messages. ##### Slow client The server sends a comment when the client is not consuming messages fast enough. Example: `: you are reading too slowly, dropped 10000 messages` ##### Internal server error An error message is sent as a comment when the server closes the connection on an internal server error (only sent by the v2 and v2beta1 endpoints). Example: `: internal server error` ---
      Parameters:
      since - Format: RFC3339 or YYYY-MM-DD (optional)
      until - Format: RFC3339 or YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      Returns:
      List<ActivityEventV2>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToActivitiesSSEWithHttpInfo

      public ApiResponse<List<ActivityEventV2>> subscribeToActivitiesSSEWithHttpInfo(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId) throws ApiException
      Subscribe to Activity Events (SSE) The Events API sends the real-time events and provides historical queries with SSE (Server Sent Events). This endpoint streams events on account activities. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query parameter rules: - If `until` is specified, `since` is required. - If `until_id` is specified, `since_id` is required. - You cannot use `since` and `since_id` together. Behavior: - If `since` or `since_id` is not specified, this will not return any historic data. - If `until` or `until_id` is specified, stream will end at the specified point with status 200. --- Warning: Currently, OAS-3 does not fully support responses from an SSE API. In case the client code is generated from this OAS spec, please do not specify `since` and `until`, as the generated client may hang forever waiting for the response to end. If you require the streaming capabilities, we recommend not using the generated clients for this specific endpoint until the OAS-3 standards define how to represent this behavior. --- ### Comment messages According to the SSE specification, any line that starts with a colon is a comment which does not contain data. It is typically a free text that does not follow any data schema. A few examples mentioned below for comment messages. ##### Slow client The server sends a comment when the client is not consuming messages fast enough. Example: `: you are reading too slowly, dropped 10000 messages` ##### Internal server error An error message is sent as a comment when the server closes the connection on an internal server error (only sent by the v2 and v2beta1 endpoints). Example: `: internal server error` ---
      Parameters:
      since - Format: RFC3339 or YYYY-MM-DD (optional)
      until - Format: RFC3339 or YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      Returns:
      ApiResponse<List<ActivityEventV2>>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToActivitiesSSEAsync

      public okhttp3.Call subscribeToActivitiesSSEAsync(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId, ApiCallback<List<ActivityEventV2>> _callback) throws ApiException
      Subscribe to Activity Events (SSE) (asynchronously) The Events API sends the real-time events and provides historical queries with SSE (Server Sent Events). This endpoint streams events on account activities. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query parameter rules: - If `until` is specified, `since` is required. - If `until_id` is specified, `since_id` is required. - You cannot use `since` and `since_id` together. Behavior: - If `since` or `since_id` is not specified, this will not return any historic data. - If `until` or `until_id` is specified, stream will end at the specified point with status 200. --- Warning: Currently, OAS-3 does not fully support responses from an SSE API. In case the client code is generated from this OAS spec, please do not specify `since` and `until`, as the generated client may hang forever waiting for the response to end. If you require the streaming capabilities, we recommend not using the generated clients for this specific endpoint until the OAS-3 standards define how to represent this behavior. --- ### Comment messages According to the SSE specification, any line that starts with a colon is a comment which does not contain data. It is typically a free text that does not follow any data schema. A few examples mentioned below for comment messages. ##### Slow client The server sends a comment when the client is not consuming messages fast enough. Example: `: you are reading too slowly, dropped 10000 messages` ##### Internal server error An error message is sent as a comment when the server closes the connection on an internal server error (only sent by the v2 and v2beta1 endpoints). Example: `: internal server error` ---
      Parameters:
      since - Format: RFC3339 or YYYY-MM-DD (optional)
      until - Format: RFC3339 or YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToAdminActionSSECall

      public okhttp3.Call subscribeToAdminActionSSECall(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId, ApiCallback _callback) throws ApiException
      Build call for subscribeToAdminActionSSE
      Parameters:
      since - Format: RFC3339 or YYYY-MM-DD (optional)
      until - Format: RFC3339 or YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToAdminActionSSE

      public List<SubscribeToAdminActionSSE200ResponseInner> subscribeToAdminActionSSE(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId) throws ApiException
      Subscribe to Admin Action Events (SSE) The Events API provides event push as well as historical queries via SSE (server sent events). This endpoint streams events related to administrative actions performed by our systems. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- Warning: Currently OAS-3 doesn't have full support for representing SSE style responses from an API. In case the client code is generated from this OAS spec, don't specify a `since` and `until` there is a good chance the generated clients will hang forever waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific endpoint until the OAS-3 standards come to a consensus on how to represent this behavior in OAS-3. --- ### Comment messages According to the SSE specification, any line that starts with a colon is a comment which does not contain data. It is typically a free text that does not follow any data schema. A few examples mentioned below for comment messages. ##### Slow client The server sends a comment when the client is not consuming messages fast enough. Example: `: you are reading too slowly, dropped 10000 messages` ##### Internal server error An error message is sent as a comment when the server closes the connection on an internal server error (only sent by the v2 and v2beta1 endpoints). Example: `: internal server error` --- **Event Types** - **LegacyNote:** Old free text based admin notes - **Liquidation:** Event for a position liquidation which initialized by an admin - **TransactionCancel:** Event for a manually cancelled transaction
      Parameters:
      since - Format: RFC3339 or YYYY-MM-DD (optional)
      until - Format: RFC3339 or YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      Returns:
      List<SubscribeToAdminActionSSE200ResponseInner>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToAdminActionSSEWithHttpInfo

      public ApiResponse<List<SubscribeToAdminActionSSE200ResponseInner>> subscribeToAdminActionSSEWithHttpInfo(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId) throws ApiException
      Subscribe to Admin Action Events (SSE) The Events API provides event push as well as historical queries via SSE (server sent events). This endpoint streams events related to administrative actions performed by our systems. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- Warning: Currently OAS-3 doesn't have full support for representing SSE style responses from an API. In case the client code is generated from this OAS spec, don't specify a `since` and `until` there is a good chance the generated clients will hang forever waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific endpoint until the OAS-3 standards come to a consensus on how to represent this behavior in OAS-3. --- ### Comment messages According to the SSE specification, any line that starts with a colon is a comment which does not contain data. It is typically a free text that does not follow any data schema. A few examples mentioned below for comment messages. ##### Slow client The server sends a comment when the client is not consuming messages fast enough. Example: `: you are reading too slowly, dropped 10000 messages` ##### Internal server error An error message is sent as a comment when the server closes the connection on an internal server error (only sent by the v2 and v2beta1 endpoints). Example: `: internal server error` --- **Event Types** - **LegacyNote:** Old free text based admin notes - **Liquidation:** Event for a position liquidation which initialized by an admin - **TransactionCancel:** Event for a manually cancelled transaction
      Parameters:
      since - Format: RFC3339 or YYYY-MM-DD (optional)
      until - Format: RFC3339 or YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      Returns:
      ApiResponse<List<SubscribeToAdminActionSSE200ResponseInner>>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToAdminActionSSEAsync

      public okhttp3.Call subscribeToAdminActionSSEAsync(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId, ApiCallback<List<SubscribeToAdminActionSSE200ResponseInner>> _callback) throws ApiException
      Subscribe to Admin Action Events (SSE) (asynchronously) The Events API provides event push as well as historical queries via SSE (server sent events). This endpoint streams events related to administrative actions performed by our systems. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- Warning: Currently OAS-3 doesn't have full support for representing SSE style responses from an API. In case the client code is generated from this OAS spec, don't specify a `since` and `until` there is a good chance the generated clients will hang forever waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific endpoint until the OAS-3 standards come to a consensus on how to represent this behavior in OAS-3. --- ### Comment messages According to the SSE specification, any line that starts with a colon is a comment which does not contain data. It is typically a free text that does not follow any data schema. A few examples mentioned below for comment messages. ##### Slow client The server sends a comment when the client is not consuming messages fast enough. Example: `: you are reading too slowly, dropped 10000 messages` ##### Internal server error An error message is sent as a comment when the server closes the connection on an internal server error (only sent by the v2 and v2beta1 endpoints). Example: `: internal server error` --- **Event Types** - **LegacyNote:** Old free text based admin notes - **Liquidation:** Event for a position liquidation which initialized by an admin - **TransactionCancel:** Event for a manually cancelled transaction
      Parameters:
      since - Format: RFC3339 or YYYY-MM-DD (optional)
      until - Format: RFC3339 or YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToFundingStatusSSECall

      public okhttp3.Call subscribeToFundingStatusSSECall(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable String sinceId, @Nullable String untilId, ApiCallback _callback) throws ApiException
      Build call for subscribeToFundingStatusSSE
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToFundingStatusSSE

      public List<SubscribeToFundingStatusSSE200ResponseInner> subscribeToFundingStatusSSE(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable String sinceId, @Nullable String untilId) throws ApiException
      Subscribe to Funding Status Events (SSE) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to funding status updates as they get processed by our backoffice, for both end-user and firm accounts. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time - `until` and `until_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      Returns:
      List<SubscribeToFundingStatusSSE200ResponseInner>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToFundingStatusSSEWithHttpInfo

      public ApiResponse<List<SubscribeToFundingStatusSSE200ResponseInner>> subscribeToFundingStatusSSEWithHttpInfo(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable String sinceId, @Nullable String untilId) throws ApiException
      Subscribe to Funding Status Events (SSE) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to funding status updates as they get processed by our backoffice, for both end-user and firm accounts. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time - `until` and `until_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      Returns:
      ApiResponse<List<SubscribeToFundingStatusSSE200ResponseInner>>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToFundingStatusSSEAsync

      public okhttp3.Call subscribeToFundingStatusSSEAsync(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable String sinceId, @Nullable String untilId, ApiCallback<List<SubscribeToFundingStatusSSE200ResponseInner>> _callback) throws ApiException
      Subscribe to Funding Status Events (SSE) (asynchronously) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to funding status updates as they get processed by our backoffice, for both end-user and firm accounts. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time - `until` and `until_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToIPOEventsSSECall

      public okhttp3.Call subscribeToIPOEventsSSECall(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId, ApiCallback _callback) throws ApiException
      Build call for subscribeToIPOEventsSSE
      Parameters:
      since - Format: RFC3339 or YYYY-MM-DD (optional)
      until - Format: RFC3339 or YYYY-MM-DD (optional)
      sinceId - ULID `event_id` to resume the stream from. The first event returned will be the one immediately after `since_id`. (optional)
      untilId - ULID `event_id` at which the stream will end (inclusive). Useful for backfills. (optional)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToIPOEventsSSE

      public List<IPOEvent> subscribeToIPOEventsSSE(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId) throws ApiException
      Subscribe to IPO Events (SSE) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to IPO offering lifecycle updates as they happen - including new offerings, offering updates, prospectus availability, the 60-minute pricing window, account-scoped allocation results, and offering cancellations. Historical events are streamed immediately if queried, and updates are pushed as events occur. --- **Event types** Each event has a `verb` field that determines the shape of `payload`. See the `IPOEvent` schema for the full payload structure for each verb. - `Offering` - initial publication of an offering (system-wide). - `OfferingUpdate` - update to a previously published offering (system-wide). - `Prospectus` - prospectus document is now available (system-wide). - `SixtyMinMail` - 60-minute pricing window has opened, no new orders accepted (system-wide). - `Allocation` - final allocation result for a specific account. **Account-scoped** - `account_id` and `correspondent` are populated. - `OfferingCancellation` - offering was cancelled. **No `payload` field is present.** Use the `offering_reference` field on each event to fetch the full offering metadata via [`GET /v1/ipos/{offering_reference}`](#operation/getIPOOffering). --- Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time - `until` and `until_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: RFC3339 or YYYY-MM-DD (optional)
      until - Format: RFC3339 or YYYY-MM-DD (optional)
      sinceId - ULID `event_id` to resume the stream from. The first event returned will be the one immediately after `since_id`. (optional)
      untilId - ULID `event_id` at which the stream will end (inclusive). Useful for backfills. (optional)
      Returns:
      List<IPOEvent>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToIPOEventsSSEWithHttpInfo

      public ApiResponse<List<IPOEvent>> subscribeToIPOEventsSSEWithHttpInfo(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId) throws ApiException
      Subscribe to IPO Events (SSE) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to IPO offering lifecycle updates as they happen - including new offerings, offering updates, prospectus availability, the 60-minute pricing window, account-scoped allocation results, and offering cancellations. Historical events are streamed immediately if queried, and updates are pushed as events occur. --- **Event types** Each event has a `verb` field that determines the shape of `payload`. See the `IPOEvent` schema for the full payload structure for each verb. - `Offering` - initial publication of an offering (system-wide). - `OfferingUpdate` - update to a previously published offering (system-wide). - `Prospectus` - prospectus document is now available (system-wide). - `SixtyMinMail` - 60-minute pricing window has opened, no new orders accepted (system-wide). - `Allocation` - final allocation result for a specific account. **Account-scoped** - `account_id` and `correspondent` are populated. - `OfferingCancellation` - offering was cancelled. **No `payload` field is present.** Use the `offering_reference` field on each event to fetch the full offering metadata via [`GET /v1/ipos/{offering_reference}`](#operation/getIPOOffering). --- Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time - `until` and `until_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: RFC3339 or YYYY-MM-DD (optional)
      until - Format: RFC3339 or YYYY-MM-DD (optional)
      sinceId - ULID `event_id` to resume the stream from. The first event returned will be the one immediately after `since_id`. (optional)
      untilId - ULID `event_id` at which the stream will end (inclusive). Useful for backfills. (optional)
      Returns:
      ApiResponse<List<IPOEvent>>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToIPOEventsSSEAsync

      public okhttp3.Call subscribeToIPOEventsSSEAsync(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId, ApiCallback<List<IPOEvent>> _callback) throws ApiException
      Subscribe to IPO Events (SSE) (asynchronously) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to IPO offering lifecycle updates as they happen - including new offerings, offering updates, prospectus availability, the 60-minute pricing window, account-scoped allocation results, and offering cancellations. Historical events are streamed immediately if queried, and updates are pushed as events occur. --- **Event types** Each event has a `verb` field that determines the shape of `payload`. See the `IPOEvent` schema for the full payload structure for each verb. - `Offering` - initial publication of an offering (system-wide). - `OfferingUpdate` - update to a previously published offering (system-wide). - `Prospectus` - prospectus document is now available (system-wide). - `SixtyMinMail` - 60-minute pricing window has opened, no new orders accepted (system-wide). - `Allocation` - final allocation result for a specific account. **Account-scoped** - `account_id` and `correspondent` are populated. - `OfferingCancellation` - offering was cancelled. **No `payload` field is present.** Use the `offering_reference` field on each event to fetch the full offering metadata via [`GET /v1/ipos/{offering_reference}`](#operation/getIPOOffering). --- Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time - `until` and `until_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: RFC3339 or YYYY-MM-DD (optional)
      until - Format: RFC3339 or YYYY-MM-DD (optional)
      sinceId - ULID `event_id` to resume the stream from. The first event returned will be the one immediately after `since_id`. (optional)
      untilId - ULID `event_id` at which the stream will end (inclusive). Useful for backfills. (optional)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToJournalStatusSSECall

      public okhttp3.Call subscribeToJournalStatusSSECall(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid, @Nullable String id, ApiCallback _callback) throws ApiException
      Build call for subscribeToJournalStatusSSE
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      id - (optional)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToJournalStatusSSE

      public List<JournalStatusEvent> subscribeToJournalStatusSSE(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid, @Nullable String id) throws ApiException
      Subscribe to Journal Events (SSE) (Legacy) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to journal status updates as they get processed by our backoffice. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since_ulid` required if `until_ulid` specified - `since`, `since_id` or `since_ulid` can't be used at the same time Behavior: - if `since`, `since_id` or `since_ulid` not specified this will not return any historic data - if `until`, `until_id` or `until_ulid` reached stream will end (status 200) --- There is no compatibility between /v1/events/journals/status and /v2/events/journals/status, the ids (ulid) are always different, and the number of events might also different Please note that the new `/v2` endpoint, is the same as, and was originally available under `/v2beta1`. We encourage all customers to adjust their codebase from that interim beta endpoint to the `/v2` stable endpoint. In the near future we will setup permanent redirect from `/v2beta1` to `/v2` before we completely remove the beta endpoint. --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      id - (optional)
      Returns:
      List<JournalStatusEvent>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToJournalStatusSSEWithHttpInfo

      public ApiResponse<List<JournalStatusEvent>> subscribeToJournalStatusSSEWithHttpInfo(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid, @Nullable String id) throws ApiException
      Subscribe to Journal Events (SSE) (Legacy) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to journal status updates as they get processed by our backoffice. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since_ulid` required if `until_ulid` specified - `since`, `since_id` or `since_ulid` can't be used at the same time Behavior: - if `since`, `since_id` or `since_ulid` not specified this will not return any historic data - if `until`, `until_id` or `until_ulid` reached stream will end (status 200) --- There is no compatibility between /v1/events/journals/status and /v2/events/journals/status, the ids (ulid) are always different, and the number of events might also different Please note that the new `/v2` endpoint, is the same as, and was originally available under `/v2beta1`. We encourage all customers to adjust their codebase from that interim beta endpoint to the `/v2` stable endpoint. In the near future we will setup permanent redirect from `/v2beta1` to `/v2` before we completely remove the beta endpoint. --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      id - (optional)
      Returns:
      ApiResponse<List<JournalStatusEvent>>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToJournalStatusSSEAsync

      public okhttp3.Call subscribeToJournalStatusSSEAsync(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid, @Nullable String id, ApiCallback<List<JournalStatusEvent>> _callback) throws ApiException
      Subscribe to Journal Events (SSE) (Legacy) (asynchronously) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to journal status updates as they get processed by our backoffice. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since_ulid` required if `until_ulid` specified - `since`, `since_id` or `since_ulid` can't be used at the same time Behavior: - if `since`, `since_id` or `since_ulid` not specified this will not return any historic data - if `until`, `until_id` or `until_ulid` reached stream will end (status 200) --- There is no compatibility between /v1/events/journals/status and /v2/events/journals/status, the ids (ulid) are always different, and the number of events might also different Please note that the new `/v2` endpoint, is the same as, and was originally available under `/v2beta1`. We encourage all customers to adjust their codebase from that interim beta endpoint to the `/v2` stable endpoint. In the near future we will setup permanent redirect from `/v2beta1` to `/v2` before we completely remove the beta endpoint. --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      id - (optional)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToJournalStatusV2SSECall

      public okhttp3.Call subscribeToJournalStatusV2SSECall(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId, @Nullable String id, ApiCallback _callback) throws ApiException
      Build call for subscribeToJournalStatusV2SSE
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      id - (optional)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToJournalStatusV2SSE

      public List<JournalStatusEventV2> subscribeToJournalStatusV2SSE(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId, @Nullable String id) throws ApiException
      Subscribe to Journal Events (SSE) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to journal status updates as they get processed by our backoffice. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time - `until` and `until_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- There is no compatibility between /v1/events/journals/status and /v2/events/journals/status, the ids (ulid) are always different, and the number of events might also different Please note that the new `/v2` endpoint, is the same as, and was originally available under `/v2beta1`. We encourage all customers to adjust their codebase from that interim beta endpoint to the `/v2` stable endpoint. In the near future we will setup permanent redirect from `/v2beta1` to `/v2` before we completely remove the beta endpoint. --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      id - (optional)
      Returns:
      List<JournalStatusEventV2>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToJournalStatusV2SSEWithHttpInfo

      public ApiResponse<List<JournalStatusEventV2>> subscribeToJournalStatusV2SSEWithHttpInfo(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId, @Nullable String id) throws ApiException
      Subscribe to Journal Events (SSE) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to journal status updates as they get processed by our backoffice. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time - `until` and `until_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- There is no compatibility between /v1/events/journals/status and /v2/events/journals/status, the ids (ulid) are always different, and the number of events might also different Please note that the new `/v2` endpoint, is the same as, and was originally available under `/v2beta1`. We encourage all customers to adjust their codebase from that interim beta endpoint to the `/v2` stable endpoint. In the near future we will setup permanent redirect from `/v2beta1` to `/v2` before we completely remove the beta endpoint. --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      id - (optional)
      Returns:
      ApiResponse<List<JournalStatusEventV2>>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToJournalStatusV2SSEAsync

      public okhttp3.Call subscribeToJournalStatusV2SSEAsync(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId, @Nullable String id, ApiCallback<List<JournalStatusEventV2>> _callback) throws ApiException
      Subscribe to Journal Events (SSE) (asynchronously) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to journal status updates as they get processed by our backoffice. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time - `until` and `until_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- There is no compatibility between /v1/events/journals/status and /v2/events/journals/status, the ids (ulid) are always different, and the number of events might also different Please note that the new `/v2` endpoint, is the same as, and was originally available under `/v2beta1`. We encourage all customers to adjust their codebase from that interim beta endpoint to the `/v2` stable endpoint. In the near future we will setup permanent redirect from `/v2beta1` to `/v2` before we completely remove the beta endpoint. --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      id - (optional)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToSystemEventV2SSECall

      public okhttp3.Call subscribeToSystemEventV2SSECall(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId, ApiCallback _callback) throws ApiException
      Build call for subscribeToSystemEventV2SSE
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToSystemEventV2SSE

      public List<SystemEventV2> subscribeToSystemEventV2SSE(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId) throws ApiException
      Subscribe to System Events (SSE) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to system event updates as they happen in our backend. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time - `until` and `until_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      Returns:
      List<SystemEventV2>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToSystemEventV2SSEWithHttpInfo

      public ApiResponse<List<SystemEventV2>> subscribeToSystemEventV2SSEWithHttpInfo(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId) throws ApiException
      Subscribe to System Events (SSE) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to system event updates as they happen in our backend. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time - `until` and `until_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      Returns:
      ApiResponse<List<SystemEventV2>>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToSystemEventV2SSEAsync

      public okhttp3.Call subscribeToSystemEventV2SSEAsync(@Nullable OffsetDateTime since, @Nullable OffsetDateTime until, @Nullable String sinceId, @Nullable String untilId, ApiCallback<List<SystemEventV2>> _callback) throws ApiException
      Subscribe to System Events (SSE) (asynchronously) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to system event updates as they happen in our backend. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time - `until` and `until_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToTradeSSECall

      @Deprecated public okhttp3.Call subscribeToTradeSSECall(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid, ApiCallback _callback) throws ApiException
      Deprecated.
      Build call for subscribeToTradeSSE
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -
      410 Deprecated. The endpoint is not available for this partner. -

    • subscribeToTradeSSE

      @Deprecated public List<TradeUpdateEvent> subscribeToTradeSSE(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid) throws ApiException
      Deprecated.
      Subscribe to Trade Events (SSE) (Legacy) **Deprecation notice** As part of the deprecation process, the legacy trade events API is now only available for existing broker-partners at: `GET /v1/events/trades` only for compatibility reasons. All new broker partners will not have the option for the legacy trade event endpoint. All new broker partners will have to integrate with the new `/v2/events/trades` endpoint. Also, all existing broker partners are now recommended to upgrade to the `/v2/events/trades` endpoint, which provides faster event delivery times. For trade events of MLeg (multi-leg) order, please use the `/v2/events/trades` endpoint. Please note that the new `/v2` endpoint, is the same as, and was originally available under `/v2beta1`. We encourage all customers to adjust their codebase from that interim beta endpoint to the `/v2` stable endpoint. In the near future we will setup permanent redirect from `/v2beta1` to `/v2` before we completely remove the beta endpoint. --- The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to events related to trade updates. Most market trades sent during market hours are filled instantly; you can listen to limit order updates through this endpoint. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since_ulid` required if `until_ulid` specified - `since`, `since_id` or `since_ulid` can't be used at the same time Behavior: - if `since`, `since_id` or `since_ulid` not specified this will not return any historic data - if `until`, `until_id` or `until_ulid` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3. --- **Deprecation note** Legacy event id (integer based) is unavailable for new broker partners, and it will be deprecated for existing brokers as well. This deprecation is includes the `since_id` and `until_id` query parameter and the `event_id` field in the response. --- **Common events** These are the events that are the expected results of actions you may have taken by sending API requests. The meaning of the timestamp field changes for each type; the meanings have been specified here for which types the timestamp field will be present. - `accepted` Sent when an order is received and accepted by Alpaca - `pending_new` Sent when the order has been received by Alpaca and routed to the exchanges, but has not yet been accepted for execution. - `new` Sent when an order has been routed to exchanges for execution. - `fill` Sent when your order has been completely filled. - timestamp: The time at which the order was filled. - `partial_fill` Sent when a number of shares less than the total remaining quantity on your order has been filled. - timestamp: The time at which the shares were filled. - `canceled` Sent when your requested cancellation of an order is processed. - timestamp: The time at which the order was canceled. - `expired` Sent when an order has reached the end of its lifespan, as determined by the order's time in force value. - timestamp: The time at which the order expired. - `done_for_day` Sent when the order is done executing for the day, and will not receive further updates until the next trading day. - `replaced` Sent when your requested replacement of an order is processed. - timestamp: The time at which the order was replaced. **Rarer events** These are events that may rarely be sent due to unexpected circumstances on the exchanges. It is unlikely you will need to design your code around them, but you may still wish to account for the possibility that they will occur. - `rejected` Sent when your order has been rejected. - `held` For multi-leg orders, the secondary orders (stop loss, take profit) will enter this state while waiting to be triggered. - `stopped` Sent when your order has been stopped, and a trade is guaranteed for the order, usually at a stated price or better, but has not yet occurred. - `pending_cancel` Sent when the order is awaiting cancellation. Most cancellations will occur without the order entering this state. - `pending_replace` Sent when the order is awaiting replacement. - `calculated` Sent when the order has been completed for the day - it is either filled or done_for_day - but remaining settlement calculations are still pending. - `suspended` Sent when the order has been suspended and is not eligible for trading. - `order_replace_rejected` Sent when the order replace has been rejected. - `order_cancel_rejected` Sent when the order cancel has been rejected. - `trade_bust`: Sent when a previously reported execution has been canceled (\"busted\") by the upstream exchange. - `trade_correct`: Sent when a previously reported trade has been corrected. For example, the exchange may have updated the price, quantity, or another execution parameter after the trade was initially reported.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      Returns:
      List<TradeUpdateEvent>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -
      410 Deprecated. The endpoint is not available for this partner. -

    • subscribeToTradeSSEWithHttpInfo

      @Deprecated public ApiResponse<List<TradeUpdateEvent>> subscribeToTradeSSEWithHttpInfo(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid) throws ApiException
      Deprecated.
      Subscribe to Trade Events (SSE) (Legacy) **Deprecation notice** As part of the deprecation process, the legacy trade events API is now only available for existing broker-partners at: `GET /v1/events/trades` only for compatibility reasons. All new broker partners will not have the option for the legacy trade event endpoint. All new broker partners will have to integrate with the new `/v2/events/trades` endpoint. Also, all existing broker partners are now recommended to upgrade to the `/v2/events/trades` endpoint, which provides faster event delivery times. For trade events of MLeg (multi-leg) order, please use the `/v2/events/trades` endpoint. Please note that the new `/v2` endpoint, is the same as, and was originally available under `/v2beta1`. We encourage all customers to adjust their codebase from that interim beta endpoint to the `/v2` stable endpoint. In the near future we will setup permanent redirect from `/v2beta1` to `/v2` before we completely remove the beta endpoint. --- The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to events related to trade updates. Most market trades sent during market hours are filled instantly; you can listen to limit order updates through this endpoint. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since_ulid` required if `until_ulid` specified - `since`, `since_id` or `since_ulid` can't be used at the same time Behavior: - if `since`, `since_id` or `since_ulid` not specified this will not return any historic data - if `until`, `until_id` or `until_ulid` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3. --- **Deprecation note** Legacy event id (integer based) is unavailable for new broker partners, and it will be deprecated for existing brokers as well. This deprecation is includes the `since_id` and `until_id` query parameter and the `event_id` field in the response. --- **Common events** These are the events that are the expected results of actions you may have taken by sending API requests. The meaning of the timestamp field changes for each type; the meanings have been specified here for which types the timestamp field will be present. - `accepted` Sent when an order is received and accepted by Alpaca - `pending_new` Sent when the order has been received by Alpaca and routed to the exchanges, but has not yet been accepted for execution. - `new` Sent when an order has been routed to exchanges for execution. - `fill` Sent when your order has been completely filled. - timestamp: The time at which the order was filled. - `partial_fill` Sent when a number of shares less than the total remaining quantity on your order has been filled. - timestamp: The time at which the shares were filled. - `canceled` Sent when your requested cancellation of an order is processed. - timestamp: The time at which the order was canceled. - `expired` Sent when an order has reached the end of its lifespan, as determined by the order's time in force value. - timestamp: The time at which the order expired. - `done_for_day` Sent when the order is done executing for the day, and will not receive further updates until the next trading day. - `replaced` Sent when your requested replacement of an order is processed. - timestamp: The time at which the order was replaced. **Rarer events** These are events that may rarely be sent due to unexpected circumstances on the exchanges. It is unlikely you will need to design your code around them, but you may still wish to account for the possibility that they will occur. - `rejected` Sent when your order has been rejected. - `held` For multi-leg orders, the secondary orders (stop loss, take profit) will enter this state while waiting to be triggered. - `stopped` Sent when your order has been stopped, and a trade is guaranteed for the order, usually at a stated price or better, but has not yet occurred. - `pending_cancel` Sent when the order is awaiting cancellation. Most cancellations will occur without the order entering this state. - `pending_replace` Sent when the order is awaiting replacement. - `calculated` Sent when the order has been completed for the day - it is either filled or done_for_day - but remaining settlement calculations are still pending. - `suspended` Sent when the order has been suspended and is not eligible for trading. - `order_replace_rejected` Sent when the order replace has been rejected. - `order_cancel_rejected` Sent when the order cancel has been rejected. - `trade_bust`: Sent when a previously reported execution has been canceled (\"busted\") by the upstream exchange. - `trade_correct`: Sent when a previously reported trade has been corrected. For example, the exchange may have updated the price, quantity, or another execution parameter after the trade was initially reported.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      Returns:
      ApiResponse<List<TradeUpdateEvent>>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -
      410 Deprecated. The endpoint is not available for this partner. -

    • subscribeToTradeSSEAsync

      @Deprecated public okhttp3.Call subscribeToTradeSSEAsync(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid, ApiCallback<List<TradeUpdateEvent>> _callback) throws ApiException
      Deprecated.
      Subscribe to Trade Events (SSE) (Legacy) (asynchronously) **Deprecation notice** As part of the deprecation process, the legacy trade events API is now only available for existing broker-partners at: `GET /v1/events/trades` only for compatibility reasons. All new broker partners will not have the option for the legacy trade event endpoint. All new broker partners will have to integrate with the new `/v2/events/trades` endpoint. Also, all existing broker partners are now recommended to upgrade to the `/v2/events/trades` endpoint, which provides faster event delivery times. For trade events of MLeg (multi-leg) order, please use the `/v2/events/trades` endpoint. Please note that the new `/v2` endpoint, is the same as, and was originally available under `/v2beta1`. We encourage all customers to adjust their codebase from that interim beta endpoint to the `/v2` stable endpoint. In the near future we will setup permanent redirect from `/v2beta1` to `/v2` before we completely remove the beta endpoint. --- The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to events related to trade updates. Most market trades sent during market hours are filled instantly; you can listen to limit order updates through this endpoint. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since_ulid` required if `until_ulid` specified - `since`, `since_id` or `since_ulid` can't be used at the same time Behavior: - if `since`, `since_id` or `since_ulid` not specified this will not return any historic data - if `until`, `until_id` or `until_ulid` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3. --- **Deprecation note** Legacy event id (integer based) is unavailable for new broker partners, and it will be deprecated for existing brokers as well. This deprecation is includes the `since_id` and `until_id` query parameter and the `event_id` field in the response. --- **Common events** These are the events that are the expected results of actions you may have taken by sending API requests. The meaning of the timestamp field changes for each type; the meanings have been specified here for which types the timestamp field will be present. - `accepted` Sent when an order is received and accepted by Alpaca - `pending_new` Sent when the order has been received by Alpaca and routed to the exchanges, but has not yet been accepted for execution. - `new` Sent when an order has been routed to exchanges for execution. - `fill` Sent when your order has been completely filled. - timestamp: The time at which the order was filled. - `partial_fill` Sent when a number of shares less than the total remaining quantity on your order has been filled. - timestamp: The time at which the shares were filled. - `canceled` Sent when your requested cancellation of an order is processed. - timestamp: The time at which the order was canceled. - `expired` Sent when an order has reached the end of its lifespan, as determined by the order's time in force value. - timestamp: The time at which the order expired. - `done_for_day` Sent when the order is done executing for the day, and will not receive further updates until the next trading day. - `replaced` Sent when your requested replacement of an order is processed. - timestamp: The time at which the order was replaced. **Rarer events** These are events that may rarely be sent due to unexpected circumstances on the exchanges. It is unlikely you will need to design your code around them, but you may still wish to account for the possibility that they will occur. - `rejected` Sent when your order has been rejected. - `held` For multi-leg orders, the secondary orders (stop loss, take profit) will enter this state while waiting to be triggered. - `stopped` Sent when your order has been stopped, and a trade is guaranteed for the order, usually at a stated price or better, but has not yet occurred. - `pending_cancel` Sent when the order is awaiting cancellation. Most cancellations will occur without the order entering this state. - `pending_replace` Sent when the order is awaiting replacement. - `calculated` Sent when the order has been completed for the day - it is either filled or done_for_day - but remaining settlement calculations are still pending. - `suspended` Sent when the order has been suspended and is not eligible for trading. - `order_replace_rejected` Sent when the order replace has been rejected. - `order_cancel_rejected` Sent when the order cancel has been rejected. - `trade_bust`: Sent when a previously reported execution has been canceled (\"busted\") by the upstream exchange. - `trade_correct`: Sent when a previously reported trade has been corrected. For example, the exchange may have updated the price, quantity, or another execution parameter after the trade was initially reported.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -
      410 Deprecated. The endpoint is not available for this partner. -

    • subscribeToTradeV2SSECall

      public okhttp3.Call subscribeToTradeV2SSECall(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable String sinceId, @Nullable String untilId, ApiCallback _callback) throws ApiException
      Build call for subscribeToTradeV2SSE
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToTradeV2SSE

      public List<TradeUpdateEventV2> subscribeToTradeV2SSE(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable String sinceId, @Nullable String untilId) throws ApiException
      Subscribe to Trade Events (SSE) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to events related to trade updates. Most market trades sent during market hours are filled instantly; you can listen to limit order updates through this endpoint. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3. --- **Legacy trade events API** **Deprecation notice** As part of the deprecation process, the legacy trade events API is now only available for existing broker-partners at: `GET /v1/events/trades` only for compatibility reasons. All new broker partners will not have the option for the legacy trade event endpoint. All new broker partners will have to integrate with the new `/v2/events/trades` endpoint. Also, all existing broker partners are now recommended to upgrade to the `/v2/events/trades` endpoint, which provides faster event delivery times. The legacy trade events api works the same way as the new one with the exception of the event_id which is an integer except of an ULID. This results in the request's since_id and until_id are also being integers. This integer is monotonically increasing over time for events. Please note that the new `/v2` endpoint, is the same as, and was originally available under `/v2beta1`. We encourage all customers to adjust their codebase from that interim beta endpoint to the `/v2` stable endpoint. In the near future we will setup permanent redirect from `/v2beta1` to `/v2` before we completely remove the beta endpoint. --- ### Comment messages According to the SSE specification, any line that starts with a colon is a comment which does not contain data. It is typically a free text that does not follow any data schema. A few examples mentioned below for comment messages. ##### Slow client The server sends a comment when the client is not consuming messages fast enough. Example: `: you are reading too slowly, dropped 10000 messages` ##### Internal server error An error message is sent as a comment when the server closes the connection on an internal server error (only sent by the v2 and v2beta1 endpoints). Example: `: internal server error` --- **Common events** These are the events that are the expected results of actions you may have taken by sending API requests. The meaning of the timestamp field changes for each type; the meanings have been specified here for which types the timestamp field will be present. - `accepted` Sent when an order is received and accepted by Alpaca - `pending_new` Sent when the order has been received by Alpaca and routed to the exchanges, but has not yet been accepted for execution. - `new` Sent when an order has been routed to exchanges for execution. - `fill` Sent when your order has been completely filled. - timestamp: The time at which the order was filled. - `partial_fill` Sent when a number of shares less than the total remaining quantity on your order has been filled. - timestamp: The time at which the shares were filled. - `canceled` Sent when your requested cancellation of an order is processed. - timestamp: The time at which the order was canceled. - `expired` Sent when an order has reached the end of its lifespan, as determined by the order's time in force value. - timestamp: The time at which the order expired. - `done_for_day` Sent when the order is done executing for the day, and will not receive further updates until the next trading day. - `replaced` Sent when your requested replacement of an order is processed. - timestamp: The time at which the order was replaced. **Rarer events** These are events that may rarely be sent due to unexpected circumstances on the exchanges. It is unlikely you will need to design your code around them, but you may still wish to account for the possibility that they will occur. - `rejected` Sent when your order has been rejected. - timestamp: The time at which the rejection occurred. - `held` For multi-leg orders, the secondary orders (stop loss, take profit) will enter this state while waiting to be triggered. - `stopped` Sent when your order has been stopped, and a trade is guaranteed for the order, usually at a stated price or better, but has not yet occurred. - `pending_cancel` Sent when the order is awaiting cancellation. Most cancellations will occur without the order entering this state. - `pending_replace` Sent when the order is awaiting replacement. - `calculated` Sent when the order has been completed for the day - it is either filled or done_for_day - but remaining settlement calculations are still pending. - `suspended` Sent when the order has been suspended and is not eligible for trading. - `order_replace_rejected` Sent when the order replace has been rejected. - `order_cancel_rejected` Sent when the order cancel has been rejected. - `trade_bust`: Sent when a previously reported execution has been canceled (\"busted\") by the upstream exchange. - `trade_correct`: Sent when a previously reported trade has been corrected. For example, the exchange may have updated the price, quantity, or another execution parameter after the trade was initially reported. - `restated`: Sent when the order is manually modified.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      Returns:
      List<TradeUpdateEventV2>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToTradeV2SSEWithHttpInfo

      public ApiResponse<List<TradeUpdateEventV2>> subscribeToTradeV2SSEWithHttpInfo(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable String sinceId, @Nullable String untilId) throws ApiException
      Subscribe to Trade Events (SSE) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to events related to trade updates. Most market trades sent during market hours are filled instantly; you can listen to limit order updates through this endpoint. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3. --- **Legacy trade events API** **Deprecation notice** As part of the deprecation process, the legacy trade events API is now only available for existing broker-partners at: `GET /v1/events/trades` only for compatibility reasons. All new broker partners will not have the option for the legacy trade event endpoint. All new broker partners will have to integrate with the new `/v2/events/trades` endpoint. Also, all existing broker partners are now recommended to upgrade to the `/v2/events/trades` endpoint, which provides faster event delivery times. The legacy trade events api works the same way as the new one with the exception of the event_id which is an integer except of an ULID. This results in the request's since_id and until_id are also being integers. This integer is monotonically increasing over time for events. Please note that the new `/v2` endpoint, is the same as, and was originally available under `/v2beta1`. We encourage all customers to adjust their codebase from that interim beta endpoint to the `/v2` stable endpoint. In the near future we will setup permanent redirect from `/v2beta1` to `/v2` before we completely remove the beta endpoint. --- ### Comment messages According to the SSE specification, any line that starts with a colon is a comment which does not contain data. It is typically a free text that does not follow any data schema. A few examples mentioned below for comment messages. ##### Slow client The server sends a comment when the client is not consuming messages fast enough. Example: `: you are reading too slowly, dropped 10000 messages` ##### Internal server error An error message is sent as a comment when the server closes the connection on an internal server error (only sent by the v2 and v2beta1 endpoints). Example: `: internal server error` --- **Common events** These are the events that are the expected results of actions you may have taken by sending API requests. The meaning of the timestamp field changes for each type; the meanings have been specified here for which types the timestamp field will be present. - `accepted` Sent when an order is received and accepted by Alpaca - `pending_new` Sent when the order has been received by Alpaca and routed to the exchanges, but has not yet been accepted for execution. - `new` Sent when an order has been routed to exchanges for execution. - `fill` Sent when your order has been completely filled. - timestamp: The time at which the order was filled. - `partial_fill` Sent when a number of shares less than the total remaining quantity on your order has been filled. - timestamp: The time at which the shares were filled. - `canceled` Sent when your requested cancellation of an order is processed. - timestamp: The time at which the order was canceled. - `expired` Sent when an order has reached the end of its lifespan, as determined by the order's time in force value. - timestamp: The time at which the order expired. - `done_for_day` Sent when the order is done executing for the day, and will not receive further updates until the next trading day. - `replaced` Sent when your requested replacement of an order is processed. - timestamp: The time at which the order was replaced. **Rarer events** These are events that may rarely be sent due to unexpected circumstances on the exchanges. It is unlikely you will need to design your code around them, but you may still wish to account for the possibility that they will occur. - `rejected` Sent when your order has been rejected. - timestamp: The time at which the rejection occurred. - `held` For multi-leg orders, the secondary orders (stop loss, take profit) will enter this state while waiting to be triggered. - `stopped` Sent when your order has been stopped, and a trade is guaranteed for the order, usually at a stated price or better, but has not yet occurred. - `pending_cancel` Sent when the order is awaiting cancellation. Most cancellations will occur without the order entering this state. - `pending_replace` Sent when the order is awaiting replacement. - `calculated` Sent when the order has been completed for the day - it is either filled or done_for_day - but remaining settlement calculations are still pending. - `suspended` Sent when the order has been suspended and is not eligible for trading. - `order_replace_rejected` Sent when the order replace has been rejected. - `order_cancel_rejected` Sent when the order cancel has been rejected. - `trade_bust`: Sent when a previously reported execution has been canceled (\"busted\") by the upstream exchange. - `trade_correct`: Sent when a previously reported trade has been corrected. For example, the exchange may have updated the price, quantity, or another execution parameter after the trade was initially reported. - `restated`: Sent when the order is manually modified.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      Returns:
      ApiResponse<List<TradeUpdateEventV2>>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToTradeV2SSEAsync

      public okhttp3.Call subscribeToTradeV2SSEAsync(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable String sinceId, @Nullable String untilId, ApiCallback<List<TradeUpdateEventV2>> _callback) throws ApiException
      Subscribe to Trade Events (SSE) (asynchronously) The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to events related to trade updates. Most market trades sent during market hours are filled instantly; you can listen to limit order updates through this endpoint. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since` and `since_id` can't be used at the same time Behavior: - if `since` or `since_id` not specified this will not return any historic data - if `until` or `until_id` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3. --- **Legacy trade events API** **Deprecation notice** As part of the deprecation process, the legacy trade events API is now only available for existing broker-partners at: `GET /v1/events/trades` only for compatibility reasons. All new broker partners will not have the option for the legacy trade event endpoint. All new broker partners will have to integrate with the new `/v2/events/trades` endpoint. Also, all existing broker partners are now recommended to upgrade to the `/v2/events/trades` endpoint, which provides faster event delivery times. The legacy trade events api works the same way as the new one with the exception of the event_id which is an integer except of an ULID. This results in the request's since_id and until_id are also being integers. This integer is monotonically increasing over time for events. Please note that the new `/v2` endpoint, is the same as, and was originally available under `/v2beta1`. We encourage all customers to adjust their codebase from that interim beta endpoint to the `/v2` stable endpoint. In the near future we will setup permanent redirect from `/v2beta1` to `/v2` before we completely remove the beta endpoint. --- ### Comment messages According to the SSE specification, any line that starts with a colon is a comment which does not contain data. It is typically a free text that does not follow any data schema. A few examples mentioned below for comment messages. ##### Slow client The server sends a comment when the client is not consuming messages fast enough. Example: `: you are reading too slowly, dropped 10000 messages` ##### Internal server error An error message is sent as a comment when the server closes the connection on an internal server error (only sent by the v2 and v2beta1 endpoints). Example: `: internal server error` --- **Common events** These are the events that are the expected results of actions you may have taken by sending API requests. The meaning of the timestamp field changes for each type; the meanings have been specified here for which types the timestamp field will be present. - `accepted` Sent when an order is received and accepted by Alpaca - `pending_new` Sent when the order has been received by Alpaca and routed to the exchanges, but has not yet been accepted for execution. - `new` Sent when an order has been routed to exchanges for execution. - `fill` Sent when your order has been completely filled. - timestamp: The time at which the order was filled. - `partial_fill` Sent when a number of shares less than the total remaining quantity on your order has been filled. - timestamp: The time at which the shares were filled. - `canceled` Sent when your requested cancellation of an order is processed. - timestamp: The time at which the order was canceled. - `expired` Sent when an order has reached the end of its lifespan, as determined by the order's time in force value. - timestamp: The time at which the order expired. - `done_for_day` Sent when the order is done executing for the day, and will not receive further updates until the next trading day. - `replaced` Sent when your requested replacement of an order is processed. - timestamp: The time at which the order was replaced. **Rarer events** These are events that may rarely be sent due to unexpected circumstances on the exchanges. It is unlikely you will need to design your code around them, but you may still wish to account for the possibility that they will occur. - `rejected` Sent when your order has been rejected. - timestamp: The time at which the rejection occurred. - `held` For multi-leg orders, the secondary orders (stop loss, take profit) will enter this state while waiting to be triggered. - `stopped` Sent when your order has been stopped, and a trade is guaranteed for the order, usually at a stated price or better, but has not yet occurred. - `pending_cancel` Sent when the order is awaiting cancellation. Most cancellations will occur without the order entering this state. - `pending_replace` Sent when the order is awaiting replacement. - `calculated` Sent when the order has been completed for the day - it is either filled or done_for_day - but remaining settlement calculations are still pending. - `suspended` Sent when the order has been suspended and is not eligible for trading. - `order_replace_rejected` Sent when the order replace has been rejected. - `order_cancel_rejected` Sent when the order cancel has been rejected. - `trade_bust`: Sent when a previously reported execution has been canceled (\"busted\") by the upstream exchange. - `trade_correct`: Sent when a previously reported trade has been corrected. For example, the exchange may have updated the price, quantity, or another execution parameter after the trade was initially reported. - `restated`: Sent when the order is manually modified.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • subscribeToTransferStatusSSECall

      @Deprecated public okhttp3.Call subscribeToTransferStatusSSECall(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid, ApiCallback _callback) throws ApiException
      Deprecated.
      Build call for subscribeToTransferStatusSSE
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -
      410 Deprecated. The endpoint is not available for this partner. -

    • subscribeToTransferStatusSSE

      @Deprecated public List<TransferStatusEvent> subscribeToTransferStatusSSE(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid) throws ApiException
      Deprecated.
      Subscribe to Transfer Events (SSE) (Legacy) **Deprecation notice** As part of the deprecation process, the legacy transfer events API is now only available for existing broker-partners at `GET /v1/events/transfers/status` and for compatibility reasons. All new broker partners will not have the option to use the legacy transfer events endpoint. They should integrate with the new `/v2/events/funding/status` endpoint instead. Also, all existing broker partners are now recommended to upgrade to the `/v2/events/funding/status` endpoint, which provides faster event delivery times. --- The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to transfer status updates as they get processed by our backoffice, for both end-user and firm accounts. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since_ulid` required if `until_ulid` specified - `since`, `since_id` or `since_ulid` can't be used at the same time Behavior: - if `since`, `since_id` or `since_ulid` not specified this will not return any historic data - if `until`, `until_id` or `until_ulid` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      Returns:
      List<TransferStatusEvent>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -
      410 Deprecated. The endpoint is not available for this partner. -

    • subscribeToTransferStatusSSEWithHttpInfo

      @Deprecated public ApiResponse<List<TransferStatusEvent>> subscribeToTransferStatusSSEWithHttpInfo(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid) throws ApiException
      Deprecated.
      Subscribe to Transfer Events (SSE) (Legacy) **Deprecation notice** As part of the deprecation process, the legacy transfer events API is now only available for existing broker-partners at `GET /v1/events/transfers/status` and for compatibility reasons. All new broker partners will not have the option to use the legacy transfer events endpoint. They should integrate with the new `/v2/events/funding/status` endpoint instead. Also, all existing broker partners are now recommended to upgrade to the `/v2/events/funding/status` endpoint, which provides faster event delivery times. --- The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to transfer status updates as they get processed by our backoffice, for both end-user and firm accounts. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since_ulid` required if `until_ulid` specified - `since`, `since_id` or `since_ulid` can't be used at the same time Behavior: - if `since`, `since_id` or `since_ulid` not specified this will not return any historic data - if `until`, `until_id` or `until_ulid` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      Returns:
      ApiResponse<List<TransferStatusEvent>>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -
      410 Deprecated. The endpoint is not available for this partner. -

    • subscribeToTransferStatusSSEAsync

      @Deprecated public okhttp3.Call subscribeToTransferStatusSSEAsync(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid, ApiCallback<List<TransferStatusEvent>> _callback) throws ApiException
      Deprecated.
      Subscribe to Transfer Events (SSE) (Legacy) (asynchronously) **Deprecation notice** As part of the deprecation process, the legacy transfer events API is now only available for existing broker-partners at `GET /v1/events/transfers/status` and for compatibility reasons. All new broker partners will not have the option to use the legacy transfer events endpoint. They should integrate with the new `/v2/events/funding/status` endpoint instead. Also, all existing broker partners are now recommended to upgrade to the `/v2/events/funding/status` endpoint, which provides faster event delivery times. --- The Events API provides event push as well as historical queries via SSE (server sent events). You can listen to transfer status updates as they get processed by our backoffice, for both end-user and firm accounts. Historical events are streamed immediately if queried, and updates are pushed as events occur. Query Params Rules: - `since` required if `until` specified - `since_id` required if `until_id` specified - `since_ulid` required if `until_ulid` specified - `since`, `since_id` or `since_ulid` can't be used at the same time Behavior: - if `since`, `since_id` or `since_ulid` not specified this will not return any historic data - if `until`, `until_id` or `until_ulid` reached stream will end (status 200) --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -
      410 Deprecated. The endpoint is not available for this partner. -

    • suscribeToAccountStatusSSECall

      public okhttp3.Call suscribeToAccountStatusSSECall(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid, @Nullable String id, ApiCallback _callback) throws ApiException
      Build call for suscribeToAccountStatusSSE
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      id - (optional)
      _callback - Callback for upload/download progress
      Returns:
      Call to execute
      Throws:
      ApiException - If fail to serialize the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • suscribeToAccountStatusSSE

      public List<AccountStatusEvent> suscribeToAccountStatusSSE(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid, @Nullable String id) throws ApiException
      Subscribe to Account Status Events (SSE) The accounts events API provides streaming of account changes as they occur, via SSE (server sent events). Past events can also be queried. Events are generated for changes to the following account properties: - account_blocked - admin_configurations - cash_interest - crypto_status - kyc_results - options - status - trading_blocked Only the changed properties are included in the event payload. Query Parameter Rules: - `since` is required if `until` specified - `since_id` is required if `until_id` specified - `since_ulid` is required if `until_ulid` specified - `since`, `since_id` and `since_ulid` can't be used at the same time Behavior: This API supports querying a range of events, starting now or in the past. If the end of the range is in the future or not specified, the connection is kept open and future events are pushed. To be specific: - if `since`, `since_id` or `since_ulid` is not specified, this will not return any historic data - if `until`, `until_id` or `until_ulid` is reached, the stream will end with a status of 200 --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      id - (optional)
      Returns:
      List<AccountStatusEvent>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • suscribeToAccountStatusSSEWithHttpInfo

      public ApiResponse<List<AccountStatusEvent>> suscribeToAccountStatusSSEWithHttpInfo(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid, @Nullable String id) throws ApiException
      Subscribe to Account Status Events (SSE) The accounts events API provides streaming of account changes as they occur, via SSE (server sent events). Past events can also be queried. Events are generated for changes to the following account properties: - account_blocked - admin_configurations - cash_interest - crypto_status - kyc_results - options - status - trading_blocked Only the changed properties are included in the event payload. Query Parameter Rules: - `since` is required if `until` specified - `since_id` is required if `until_id` specified - `since_ulid` is required if `until_ulid` specified - `since`, `since_id` and `since_ulid` can't be used at the same time Behavior: This API supports querying a range of events, starting now or in the past. If the end of the range is in the future or not specified, the connection is kept open and future events are pushed. To be specific: - if `since`, `since_id` or `since_ulid` is not specified, this will not return any historic data - if `until`, `until_id` or `until_ulid` is reached, the stream will end with a status of 200 --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      id - (optional)
      Returns:
      ApiResponse<List<AccountStatusEvent>>
      Throws:
      ApiException - If fail to call the API, e.g. server error or cannot deserialize the response body
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -

    • suscribeToAccountStatusSSEAsync

      public okhttp3.Call suscribeToAccountStatusSSEAsync(@Nullable LocalDate since, @Nullable LocalDate until, @Nullable Integer sinceId, @Nullable Integer untilId, @Nullable String sinceUlid, @Nullable String untilUlid, @Nullable String id, ApiCallback<List<AccountStatusEvent>> _callback) throws ApiException
      Subscribe to Account Status Events (SSE) (asynchronously) The accounts events API provides streaming of account changes as they occur, via SSE (server sent events). Past events can also be queried. Events are generated for changes to the following account properties: - account_blocked - admin_configurations - cash_interest - crypto_status - kyc_results - options - status - trading_blocked Only the changed properties are included in the event payload. Query Parameter Rules: - `since` is required if `until` specified - `since_id` is required if `until_id` specified - `since_ulid` is required if `until_ulid` specified - `since`, `since_id` and `since_ulid` can't be used at the same time Behavior: This API supports querying a range of events, starting now or in the past. If the end of the range is in the future or not specified, the connection is kept open and future events are pushed. To be specific: - if `since`, `since_id` or `since_ulid` is not specified, this will not return any historic data - if `until`, `until_id` or `until_ulid` is reached, the stream will end with a status of 200 --- Note for people using the clients generated from this OAS spec. Currently OAS-3 doesn't have full support for representing SSE style responses from an API, so if you are using a generated client and don't specify a `since` and `until` there is a good chance the generated clients will hang waiting for the response to end. If you require the streaming capabilities we recommend not using the generated clients for this specific usecase until the OAS-3 standards come to a consensus on how to represent this correctly in OAS-3.
      Parameters:
      since - Format: YYYY-MM-DD (optional)
      until - Format: YYYY-MM-DD (optional)
      sinceId - (optional)
      untilId - (optional)
      sinceUlid - (optional)
      untilUlid - (optional)
      id - (optional)
      _callback - The callback to be executed when the API call finishes
      Returns:
      The request call
      Throws:
      ApiException - If fail to process the API call, e.g. serializing the request body object
      HTTP Response Details:
      Response Details
      Status Code Description Response Headers
      200 Connected. Events will now start streaming as long as you keep the connection open. -