AnyGas Verification API

openapi: 3.2.0
info:
  title: Anygas Xyz Verification API
  version: 3.28.2
  contact:
    name: Robyn AnyGas
    url: https://anygas.xyz
  license:
    name: Service terms
    url: https://anygas.xyz/svc/api/terms
  x-lastUpdated: '2026-07-29'
  description: 'Operations tagged verification across 2 of this provider''s published API definitions: anygas-openapi.json, anygas-xyz-openapi.json. Each path carries the servers of the definition it was published in.'
servers:
- url: https://api.anygas.xyz/svc
  description: Production gateway (also https://anygas.xyz/svc)
tags:
- name: Verification
  description: Check what actually happened against chain state, with caller-supplied post-conditions.
paths:
  /api/outcome/verify/{id}:
    parameters:
    - name: id
      in: path
      required: true
      schema:
        type: string
      example: fl_reconproof_msaxh1ls
    - name: recipient
      in: query
      required: false
      schema:
        type: string
      description: 'Post-condition: assert the address that must have been credited.'
    - name: minAmount
      in: query
      required: false
      schema:
        type: string
      description: 'Post-condition: assert the minimum base units that must have arrived.'
    get:
      tags:
      - Verification
      summary: Verify a settled transfer against the destination chain (not against our…
      operationId: verifyOutcome
      description: 'Every relay answers "did it work?" by reading its own row and saying yes — a relay that has mis-delivered has a database that still says DONE. This checks the DESTINATION CHAIN: it fetches the payout transaction, decodes its ERC-20 Transfer logs, and reports what actually happened. You supply the post-conditions (`recipient`, `minAmount`) and we tell you whether reality matches. It also cross-checks our own receipt against the chain and will say so, in plain terms, if our books disagree. THREE-VALUED: `verified` | `failed` | `undetermined`. `undetermined` (chain unreachable, tx not yet mined, unknown id) is NOT a pass — collapsing "could not check" into "fine" is how a loss gets reported as a success. The response includes the destination tx hash so you can reproduce the whole result yourself without trusting us. COVERS EVERY RAIL, and is candid about the ones it cannot re-derive: Allbridge, Chainflip, Solana and Tron settlements record completion as an observed BALANCE DELTA rather than a transaction we can fetch and decode, and non-EVM destinations are not reachable via EVM JSON-RPC. Those return `undetermined` with the reason stated — never `verified` on the strength of a database row. For non-EVM destinations it now QUERIES the chain and returns a `balanceObservation` (live balance vs recorded baseline plus delivered amount). That observation is reported alongside the verdict and never replaces it: a balance cannot prove a specific transfer, because tokens are fungible and recipients spend them, so the verdict stays `undetermined`.'
      responses:
        '200':
          description: Verdict plus each assertion checked against chain state
          content:
            application/json:
              schema:
                type: object
        '404':
          description: No settled transfer with that id — verdict undetermined, never verified
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
    servers:
    - url: https://api.anygas.xyz/svc
      description: Production gateway (also https://anygas.xyz/svc)
  /api/refusal/info:
    get:
      tags:
      - Verification
      summary: What refusal receipts are and how to get one
      operationId: refusalInfo
      responses:
        '200':
          description: Explanation, signer address, and how to verify offline
          content:
            application/json:
              schema:
                type: object
    servers:
    - url: https://api.anygas.xyz/svc
      description: Production gateway (also https://anygas.xyz/svc)
  /api/refusal/recent:
    get:
      tags:
      - Verification
      summary: Recently issued refusal receipts
      operationId: recentRefusals
      parameters:
      - name: limit
        in: query
        required: false
        schema:
          type: integer
          default: 25
          maximum: 200
      responses:
        '200':
          description: Signed refusal receipts, each independently verifiable
          content:
            application/json:
              schema:
                type: object
    servers:
    - url: https://api.anygas.xyz/svc
      description: Production gateway (also https://anygas.xyz/svc)
  /api/refusal/verify:
    post:
      tags:
      - Verification
      summary: Verify a signed refusal receipt
      operationId: verifyRefusal
      description: 'When a payment provider says no, the AGENT carries the blame: its principal sees an incomplete task and has only the agent’s account of why. "The relay refused me" is indistinguishable from "I got it wrong" or "I never tried". Send `x-anygas-receipt: 1` on any request and, IF we refuse it, the error response carries a signed `refusalReceipt` recording what was asked, when, and the reason we actually returned. Hand it to your principal; they verify it against our published signer address. Rewrite the reason or the error code and verification fails — the digest is recomputed from the submitted fields, never taken from the `digest` field, so blame cannot be shifted in either direction. A receipt proves the refusal HAPPENED. It is explicitly not a claim that the refusal was correct — use it to evidence that you were blocked, or to contest the decision with us. Receipts are opt-in and error-only: successful requests never mint one.'
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
      responses:
        '200':
          description: valid true/false, recomputed digest, recovered signer, and why
          content:
            application/json:
              schema:
                type: object
    servers:
    - url: https://api.anygas.xyz/svc
      description: Production gateway (also https://anygas.xyz/svc)
  /api/evidence/bundle/{id}:
    parameters:
    - name: id
      in: path
      required: true
      schema:
        type: string
      example: fl_reconproof_msaxh1ls
    - name: recipient
      in: query
      required: false
      schema:
        type: string
      description: assert who should have been paid
    - name: minAmount
      in: query
      required: false
      schema:
        type: string
      description: assert the minimum that should have arrived
    get:
      tags:
      - Verification
      summary: One signed bundle of ALL evidence about a transfer
      operationId: evidenceBundle
      description: 'Robyn can answer four separate questions about a transfer — did it happen (on-chain verification), where did every unit of the fee go, was this the better route, and is the delivery time measured or guessed. Making four calls and stitching the answers together is work an agent will skip, and four unrelated JSON blobs are not something a principal can check. This is one call and ONE SIGNATURE over the assembled whole. READ `verdict` BEFORE RELYING ON IT: the bundle verdict is the WEAKEST of its parts, never the strongest — a complete fee breakdown does not make an unverified transfer settled. Components that could not be produced appear as `unavailable` WITH a reason and are listed in `incomplete`; they are never silently omitted, because a bundle missing a check must not read like one that passed.'
      responses:
        '200':
          description: 'Assembled, signed evidence: outcome, fees, counterfactual, delivery basis'
          content:
            application/json:
              schema:
                type: object
    servers:
    - url: https://api.anygas.xyz/svc
      description: Production gateway (also https://anygas.xyz/svc)
  /api/evidence/verify:
    post:
      tags:
      - Verification
      summary: Verify a signed evidence bundle
      operationId: verifyEvidence
      description: Recomputes the digest from the SUBMITTED components — never the supplied `digest` — so swapping any single part (a fee line, an on-chain check, the counterfactual, the transfer id, even the issue timestamp) invalidates it. Without that, a bundle would be a convenient vehicle for laundering a false conclusion through a genuine signature. A valid signature means the CONTENTS are authentic; it does not mean the transfer succeeded. A genuine bundle can honestly report a failure.
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
      responses:
        '200':
          description: valid, recomputed digest, recovered signer
          content:
            application/json:
              schema:
                type: object
    servers:
    - url: https://api.anygas.xyz/svc
      description: Production gateway (also https://anygas.xyz/svc)
  /api/counterparty/check:
    post:
      tags:
      - Verification
      summary: Have I paid this address before?
      operationId: counterpartyCheck
      description: 'Address substitution is the most common theft in this space and it is silent — one hex string looks exactly like another. Signed payment requests solve it when the payee cooperates; this covers the other half: an agent about to pay an address it has never paid, with nothing telling it so. Returns YOUR OWN history with the address: times paid, how recently, typical amount, and whether this amount is unusual for that counterparty. IT IS NOT A REPUTATION SCORE. It says nothing about whether the address is honest, and a FAMILIAR ADDRESS IS NOT A SAFE ADDRESS — keys get compromised. A `first-time-recipient` result is not a warning about the recipient either; every legitimate relationship has a first payment. It is the moment to confirm the address by a second channel. READ `coverage`: the float-lane ledger does not retain recipient addresses, so float-lane payouts are excluded and "first time" can be wrong. Surfaced automatically as a WARNING (never a blocker) in /api/preflight/full.'
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
      responses:
        '200':
          description: history, signal and explicit limits
          content:
            application/json:
              schema:
                type: object
        '400':
          description: invalid address
          content:
            application/json:
              schema:
                type: object
    servers:
    - url: https://api.anygas.xyz/svc
      description: Production gateway (also https://anygas.xyz/svc)
components:
  schemas:
    Error:
      type: object
      description: Every error carries a stable errorCode plus recovery metadata. The legacy `error` string is retained for backward compatibility - branch on errorCode.
      properties:
        error:
          type: string
          description: human-readable message (legacy field)
        errorCode:
          type: string
          example: INSUFFICIENT_FLOAT
          description: stable machine code; see GET /api/errors for the full catalogue
        retryable:
          type: boolean
        retryAfterMs:
          type: integer
          description: present when the failure is transient
        suggestedAction:
          type: string
          description: what the caller should actually do next
        docs:
          type: string
      required:
      - error
x-refined-from:
- anygas-openapi.json
- anygas-xyz-openapi.json