> ## Documentation Index
> Fetch the complete documentation index at: https://nexus.gerowallet.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Your swap counter

> How many swaps were built, submitted and confirmed through the key that authenticates this call in the last 24 hours, 7 days and 30 days, and the ADA volume that moved. Counts only: no amount per swap, no transaction hash, no wallet, no fee, share or revenue figure. That is why, unlike every other /api/partner endpoint, this one also answers to a PUBLIC partner key from a registered origin, so a live counter can run in your page with the same key the widget uses.

Called with an API key (public partner or ordinary), the figures are that key's alone. Called over a Nexus dashboard session, they cover all of your personal keys.

Windows nest and are bucketed by build time: 24h is a rolling window ending now; 7d and 30d are whole UTC calendar days ending today, so 7d spans between six and seven days. `submitted` means a transaction hash exists, whatever happened afterwards. `volumeOrders` below `confirmed` means the ADA volume covers only that fraction of the swaps, because the engine did not record an ADA notional on the rest.

Poll every 15 seconds at most; the response is cacheable for that long and the server answers from the same reading inside it.



## OpenAPI

````yaml https://nexus.gerowallet.io/v3/api-docs get /api/partner/swaps/summary
openapi: 3.1.0
info:
  title: Nexus API
  description: >-
    Multi-chain blockchain data API for Cardano (and Apex), Bitcoin, and
    Midnight.


    ## Blockchains & Networks

    Endpoints are grouped by **blockchain**. Pick the target **network** with
    the

    `network` query parameter. A network is an environment *within* a
    blockchain,

    not a separate endpoint family.


    - **Cardano & Apex**: one shared set of UTxO endpoints serves
    `CARDANO_MAINNET`,
      `CARDANO_PREPROD`, `CARDANO_PREVIEW`, `APEX_PRIME_MAINNET`, `APEX_VECTOR_MAINNET`,
      `APEX_VECTOR_TESTNET`
    - **Bitcoin**: `BITCOIN_MAINNET`, `BITCOIN_TESTNET4`

    - **Midnight**: `MIDNIGHT_MAINNET`, `MIDNIGHT_PREPROD`, `MIDNIGHT_STAGENET`


    These are the values published on each operation's `network` schema, and
    what

    generated clients send. A kebab-case alias (`cardano-mainnet`) is also
    accepted,

    and matching is case-insensitive — see the note on the parameter itself.


    ### Key scope: one chain, one network

    Each API key is scoped to **one chain and one network**, fixed at creation
    time.

    A `CARDANO_MAINNET` key cannot query `CARDANO_PREPROD`, and it cannot query

    Bitcoin or Midnight at all. Create one key per chain and network under the
    same

    account. Sending a `network` value that does not match the key returns

    **400 Network Mismatch**; omit the parameter and the request runs against
    the

    key's own network.


    What is uniform across chains is the integration surface, not the
    credential:

    one account, one base URL, one auth header, one docs site.


    ## Authentication

    Send your API key in the `X-Api-Key` header. This is the credential for

    programmatic access (create one in the dashboard; keys start with `nxs_`).

    `Authorization: Bearer <token>` is only for JWT **session** tokens issued by

    `/api/auth/login` (browser/mobile apps), not for API keys.


    ## Add-ons

    Capability is gated separately from network scope. Market data, wallet
    analytics,

    transaction building, MCP, and IPFS are paid add-ons; those endpoints return

    **402 Payment Required** on a key whose plan does not carry the matching
    add-on,

    even when the chain and network match.
  contact:
    name: Nexus Team
    url: https://nexus.gerowallet.io/support
    email: nexus@gerowallet.io
  license:
    name: Apache 2.0
    url: https://www.apache.org/licenses/LICENSE-2.0.html
  version: 1.0.0
servers:
  - url: https://nexus.gerowallet.io
    description: API Server
security:
  - apiKeyAuth: []
  - bearerAuth: []
tags:
  - name: Cardano · Blocks
    description: Cardano Block API
  - name: Cardano · Policy
    description: Cardano Policy API
  - name: IPFS
    description: IPFS Content Resolution API
  - name: Bitcoin · Ordinals
    description: Ordinals + runes metadata (ord indexer)
  - name: Partner
    description: Aggregator revenue share for partner key holders
  - name: Cardano · Metadata
    description: Label-scoped transaction metadata API
  - name: Cardano · Assets
    description: Token Registry Metadata
  - name: Cardano · Transactions
    description: Cardano Transactions API
  - name: Midnight · Transactions
    description: Midnight-specific transaction endpoints (unshielded UTXOs)
  - name: Bitcoin · Mempool
    description: Bitcoin mempool snapshot
  - name: Midnight · DUST
    description: DUST registration + generation status
  - name: Cardano · Stake Pools
    description: >-
      Cardano stake pool information including registrations, retirements, and
      pool metadata
  - name: Cardano · Network
    description: Cardano Network API - Query static network / genesis parameters
  - name: Cardano · Addresses
    description: Cardano Address API
  - name: Bitcoin · Addresses
    description: >-
      Bitcoin address-keyed queries: stats / balance / UTxOs via electrs;
      ordinals via ord
  - name: Bitcoin · Transactions
    description: Bitcoin transaction lookup and submission
  - name: Cardano · Governance
    description: >-
      Cardano on-chain governance: DReps, governance actions + votes,
      constitutional committee, constitution
  - name: Cardano · DReps
    description: >-
      Cardano delegate representatives (DReps): voting power, status, metadata,
      delegators
  - name: Cardano · Transaction Builder
    description: >-
      Cardano transaction building API. Builds unsigned transactions server-side
      for client-side signing and submission. Network can be specified in the
      request body or as a query parameter. Body takes precedence over query
      parameter.
  - name: Cardano · Assets
    description: Cardano Asset API
  - name: Cardano · Accounts
    description: Cardano Account API
  - name: Bitcoin · Fees
    description: Bitcoin fee-rate estimates by confirmation block target
  - name: Bitcoin · Blocks
    description: Bitcoin block lookup
  - name: Cardano · Handles
    description: ADA Handle resolution
  - name: Cardano Market Data
    description: Endpoints from cardano-market-data
  - name: Midnight · Indexer
    description: Transparent proxy to the Midnight GraphQL indexer
  - name: Cardano · Scripts
    description: Cardano script & datum API
  - name: Cardano · Epochs
    description: Cardano Epoch API - Query protocol parameters and epoch information
  - name: Bitcoin · Chain
    description: Bitcoin chain-tip and sync state
paths:
  /api/partner/swaps/summary:
    get:
      tags:
        - Partner
      summary: Your swap counter
      description: >-
        How many swaps were built, submitted and confirmed through the key that
        authenticates this call in the last 24 hours, 7 days and 30 days, and
        the ADA volume that moved. Counts only: no amount per swap, no
        transaction hash, no wallet, no fee, share or revenue figure. That is
        why, unlike every other /api/partner endpoint, this one also answers to
        a PUBLIC partner key from a registered origin, so a live counter can run
        in your page with the same key the widget uses.


        Called with an API key (public partner or ordinary), the figures are
        that key's alone. Called over a Nexus dashboard session, they cover all
        of your personal keys.


        Windows nest and are bucketed by build time: 24h is a rolling window
        ending now; 7d and 30d are whole UTC calendar days ending today, so 7d
        spans between six and seven days. `submitted` means a transaction hash
        exists, whatever happened afterwards. `volumeOrders` below `confirmed`
        means the ADA volume covers only that fraction of the swaps, because the
        engine did not record an ADA notional on the rest.


        Poll every 15 seconds at most; the response is cacheable for that long
        and the server answers from the same reading inside it.
      operationId: summary
      responses:
        '200':
          description: The counter for the authenticated key
          content:
            '*/*':
              schema:
                $ref: '#/components/schemas/PartnerSwapSummaryResponse'
        '401':
          description: No session or API key
          content:
            '*/*':
              schema:
                $ref: '#/components/schemas/PartnerSwapSummaryResponse'
        '403':
          description: A public partner key called from an origin not registered on it
          content:
            '*/*':
              schema:
                $ref: '#/components/schemas/PartnerSwapSummaryResponse'
        '503':
          description: >-
            The swap engine cannot be reached (errorCode
            AGGREGATOR_METRICS_UNAVAILABLE). Retry; never render it as zero
          content:
            '*/*':
              schema:
                $ref: '#/components/schemas/PartnerSwapSummaryResponse'
components:
  schemas:
    PartnerSwapSummaryResponse:
      type: object
      default: null
      description: >-
        Swap counts and ADA volume for the authenticated key over the last 24
        hours, 7 days and 30 days.
      properties:
        asOf:
          type: string
          format: date-time
          default: ''
          description: When the figures were computed. Every window ends here.
        last24h:
          $ref: '#/components/schemas/PartnerSwapWindow'
        last7d:
          $ref: '#/components/schemas/PartnerSwapWindow'
        last30d:
          $ref: '#/components/schemas/PartnerSwapWindow'
    PartnerSwapWindow:
      type: object
      default: null
      description: Swap counts and ADA volume over one window, bucketed by build time.
      properties:
        window:
          type: string
          default: ''
          description: 24h, 7d or 30d.
          example: 24h
        from:
          type: string
          format: date-time
          default: ''
          description: >-
            Inclusive start of the window. Rolling for 24h; midnight UTC for 7d
            and 30d.
        to:
          type: string
          format: date-time
          default: ''
          description: When the figures were computed.
        builds:
          type: integer
          format: int64
          default: ''
          description: Swap transactions built in the window.
          example: 42
        submitted:
          type: integer
          format: int64
          default: ''
          description: Of those, the ones the wallet submitted (a transaction hash exists).
          example: 37
        confirmed:
          type: integer
          format: int64
          default: ''
          description: Of those, the ones that confirmed on chain.
          example: 35
        volumeAda:
          type: number
          default: ''
          description: ADA notional of the confirmed swaps that carry one, in ADA.
          example: 12500.5
        volumeOrders:
          type: integer
          format: int64
          default: ''
          description: >-
            How many confirmed swaps carried a notional; below confirmed means
            partial coverage.
          example: 35
  securitySchemes:
    apiKeyAuth:
      type: apiKey
      description: >-
        ### API key (programmatic access — recommended)

        Send your API key in the `X-Api-Key` header. Keys start with `nxs_` and
        are

        created in the dashboard (or via **POST /api/keys** with a session JWT).


        Each key is scoped to **one chain and one network** (for example

        `CARDANO_MAINNET`), fixed at creation time. It cannot query a different
        network

        on the same chain, and it cannot query a different chain at all. A
        mismatched

        `network` parameter returns **400 Network Mismatch**. Create one key per
        chain

        and network under the same account.


        This is the credential most integrations should use.
      name: X-Api-Key
      in: header
    bearerAuth:
      type: http
      description: >-
        ### JWT session token (browser / mobile apps)

        A short-lived JWT issued by `/api/auth/login` or `/api/auth/device`,
        sent as

        `Authorization: Bearer <token>`. This is the **session** credential for
        the web

        dashboard and mobile apps, not for server-to-server API access.


        For programmatic API access use an **API key** in the `X-Api-Key` header

        instead — do **not** put an `nxs_` API key in this Bearer field.
      scheme: bearer
      bearerFormat: JWT

````