generated: '2026-09-06'
method: searched
source: >-
  https://github.com/acres4/foundation-documentation/blob/master/apis/event/1.4/usage.md (channels,
  filters, packet envelope, performance limits), https://github.com/acres4/ios-sdk (BLE write
  operations and their reversal) and https://acresmanufacturing.com/faq/ (transport + auth).
description: >-
  Cross-cutting runtime semantics of the Acres public developer surface. Two very different
  surfaces sit here: the Foundation Event Replay API, a READ-ONLY WebSocket stream, and the
  AcresBLE mobile SDKs, which do write (fund a table, cash out, card a player in) but over
  Bluetooth GATT rather than HTTP.
api_style: >-
  WebSocket (RFC 6455) server-push, JSON payloads, query-string filters. No REST resource surface,
  no GraphQL, no gRPC and no SOAP is published.
base_url: wss://{property}.kailabor.com/nex7/sas-reader/ws
authentication:
  scheme: Mutual TLS (client certificate), per the provider FAQ; nothing documented in the API reference.
  detail: authentication/acres-manufacturing-authentication.yml
pagination:
  style: index-cursor and time-window (streaming, not paged responses)
  request_params:
    start_idx: Global idx to read from (real-time channel; removed from the historical channel in 1.4.3).
    end_idx: Global idx upper bound (historical channel; removed in 1.4.3).
    start: Window start, nanoseconds since the Unix epoch (historical channel).
    end: Window end, nanoseconds since the Unix epoch (historical channel).
    limit: Maximum packets processed before sending to the client; ignored when the query is bounded by idx.
  response_fields:
    idx: Monotonically increasing global order over the whole stream — the resumption cursor.
    sas_queue_index: Order within one Bridge board.
    hdr_id: Order within one GMI.
  note: >-
    A consumer resumes by remembering the last idx it processed. The real-time channel keeps a
    replay cache of at most 10,000 events or 10 minutes, whichever is smaller, so a consumer that
    is offline longer than that must fall back to the historical channel.
filtering:
  params: [sas_codes, asset_number, sas_serial_number]
  semantics: >-
    asset_number and sas_serial_number are OR'd against each other when both are supplied;
    sas_codes filters by SAS 6.02 Appendix A Table A-1 exception code in decimal notation.
metadata:
  supported: false
request_tracing:
  request_id_header: none
  mechanism: Packet-level idx / sas_queue_index / hdr_id / dest identify the ordering and origin device.
versioning:
  scheme: Documented API version per folder in the documentation repository (1.2, 1.3, 1.4 with 1.4.2 and 1.4.3 revisions).
  mechanism: >-
    No version header, path segment or query parameter is documented. The version a consumer gets
    is the Foundation build deployed at their property, which makes version discovery an
    out-of-band conversation with the operator.
  current: '1.4.3'
  detail: lifecycle/acres-manufacturing-lifecycle.yml
error_envelope:
  media_type: none
  documented: false
  known_errors:
  - status: 400
    condition: The request was not upgraded to a WebSocket.
    source: https://github.com/acres4/foundation-documentation/blob/master/apis/event/1.4/usage.md
  note: >-
    No error object, code registry or problem+json envelope is published. Authentication,
    authorization and filter-validation failures are undocumented, which is why no ErrorCatalog
    artifact was written — one error condition is not a catalog and asserting otherwise would
    credit Acres with error semantics it has not published.
rate_limit_signaling:
  headers: none
  mechanism: >-
    No RateLimit-*/Retry-After headers and no 429 are documented. The provider instead publishes
    throughput guidance: a maximum query limit tied to how fast the CLIENT consumes packets, and a
    warning that slower clients may not receive every packet the server sent.
  detail: rate-limits/acres-manufacturing-rate-limits.yml
idempotency:
  supported: false
  coverage: na
  mechanism: none
  rationale: >-
    The Foundation Event Replay API has no write surface — both channels are subscribe-only — so
    replay protection has nothing to protect. Re-reading is deterministic by design: the provider
    states that processing the same underlying packets yields the same set of flattened packets
    across multiple trials, and a bounded (start_idx/end_idx or start/end) query returns the same
    window every time.
  na_reason: read-only API
dry_run_mode:
  supported: false
  coverage: na
  na_reason: read-only API — nothing to rehearse.
reversibility:
  api_surface:
    grade: na
    na_reason: >-
      The public Foundation Event Replay API is read-only. There is no state-changing operation to
      reverse, so reversibility does not apply to it.
  sdk_surface:
    grade: documented
    scope: AcresBLE SDK (iOS + Android) — the only documented write operations Acres publishes.
    source: https://github.com/acres4/ios-sdk/blob/main/README.md
    operations:
    - action: cashOutTable
      description: Notifies the dealer of an impending cash-out by writing zero to the amount characteristic; the dealer enters an amount and the player is prompted to accept.
      reversal: cancelCashOut
      reversal_description: Rejects the cash-out amount suggested by the dealer.
      window: not stated
    - action: insertPlayerCard
      description: Cards a player into an EGM by writing the card track.
      reversal: removePlayerCard
      reversal_description: Cards the player out by writing false to the player-card-insert characteristic.
      window: not stated
    - action: fundTable
      description: Requests dealer permission to transfer an amount to a table game.
      reversal: none documented
      window: not stated
    grade_rationale: >-
      Reversal paths exist and are named in the provider's own SDK reference, but no time or state
      window is stated for any of them, so this grades `documented` (0.4) and not `verified` (1.0).
      No window was inferred — inventing one here could cost a casino or a player real money.