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

# Recover a failed deposit with an owner signature

> Return a failed or rejected deposit's source-chain funds to a destination the user signed for, authorized by the deposit RECIPIENT's EIP-712 signature rather than by the API key. The server reconstructs the RecoverDeposit typed data from the stored deposit row and verifies the signature against that row's `recipient` — on the deposit's TARGET chain, where the recipient wallet lives — accepting a raw ECDSA signature (embedded EOA), an ERC-1271 signature (deployed smart account) or an ERC-6492 wrapper (counterfactual account). It then runs the same claim + transfer path as the refund endpoint. Because the signature is the authorization boundary, this route is safe to expose to a browser and a read-scoped `x-api-key` is sufficient. EVM on both source and target chains.



## OpenAPI

````yaml https://raw.githubusercontent.com/rhinestonewtf/openapi/refs/heads/main/deposit-service.json post /deposits/recover
openapi: 3.1.0
info:
  title: Deposit Service API
  version: 1.0.0
  description: >-
    Cross-chain deposit processing service with automatic token bridging and gas
    sponsorship
servers:
  - url: https://v1.orchestrator.rhinestone.dev/deposit-processor
security: []
paths:
  /deposits/recover:
    post:
      tags:
        - Processing
      summary: Recover a failed deposit with an owner signature
      description: >-
        Return a failed or rejected deposit's source-chain funds to a
        destination the user signed for, authorized by the deposit RECIPIENT's
        EIP-712 signature rather than by the API key. The server reconstructs
        the RecoverDeposit typed data from the stored deposit row and verifies
        the signature against that row's `recipient` — on the deposit's TARGET
        chain, where the recipient wallet lives — accepting a raw ECDSA
        signature (embedded EOA), an ERC-1271 signature (deployed smart account)
        or an ERC-6492 wrapper (counterfactual account). It then runs the same
        claim + transfer path as the refund endpoint. Because the signature is
        the authorization boundary, this route is safe to expose to a browser
        and a read-scoped `x-api-key` is sufficient. EVM on both source and
        target chains.
      parameters:
        - schema:
            type: string
            description: API key for authentication (omit when sending Authorization)
            example: your-api-key
          required: false
          description: API key for authentication (omit when sending Authorization)
          name: x-api-key
          in: header
        - schema:
            type: string
            description: >-
              Bearer platform token (e.g. forwarded by user-service). Takes
              precedence over `x-api-key` when both are present.
            example: Bearer eyJhbGciOi...
          required: false
          description: >-
            Bearer platform token (e.g. forwarded by user-service). Takes
            precedence over `x-api-key` when both are present.
          name: authorization
          in: header
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/RecoverDepositRequestBody'
      responses:
        '200':
          description: Deposit recovered; funds returned on the source chain
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/RefundDepositResponse'
        '400':
          description: >-
            Deposit not recoverable (DEPOSIT_NOT_RECOVERABLE) or unsupported for
            signed recovery (RECOVERY_UNSUPPORTED)
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/RecoverDepositErrorResponse'
        '401':
          description: Authentication required or invalid
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'
        '403':
          description: API key lacks the deposits:write scope
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'
        '409':
          description: >-
            The refund may have been submitted and is held for reconciliation
            (REFUND_RECONCILIATION_REQUIRED)
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/RecoverDepositErrorResponse'
        '422':
          description: The signature does not authorize this recovery (SIGNATURE_INVALID)
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/RecoverDepositErrorResponse'
        '500':
          description: Recovery transfer failed (REFUND_FAILED)
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/RecoverDepositErrorResponse'
        '503':
          description: >-
            Smart-account signature verification is temporarily unavailable
            (VERIFICATION_UNAVAILABLE)
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/RecoverDepositErrorResponse'
components:
  schemas:
    RecoverDepositRequestBody:
      type: object
      properties:
        depositId:
          type: string
          pattern: ^\d+$
          description: >-
            Deposit id, as returned by `GET /deposits`. Identifies the row
            directly: one transaction can produce several deposits, so a {chain,
            txHash, account, token} tuple does not.
          example: '2551'
        destination:
          type: string
          pattern: ^0x[a-fA-F0-9]{40}$
          description: >-
            Address to receive the recovered tokens on the deposit's source
            chain. Covered by the signature, so the caller cannot redirect an
            authorized recovery.
          example: '0x742d35Cc6634C0532925a3b844Bc9e7595f5bE91'
        signature:
          type: string
          minLength: 132
          maxLength: 8194
          pattern: ^0x([a-fA-F0-9]{2})+$
          description: >-
            Signature by the deposit recipient over the RecoverDeposit typed
            data, in whatever form that account verifies: raw ECDSA (EOA),
            ERC-1271 (deployed smart account), or ERC-6492-wrapped (undeployed).
          example: >-
            0x1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
      required:
        - depositId
        - destination
        - signature
    RefundDepositResponse:
      type: object
      properties:
        message:
          type: string
        transactionHash:
          type: string
        amount:
          type: string
      required:
        - message
        - transactionHash
        - amount
    RecoverDepositErrorResponse:
      type: object
      properties:
        error:
          type: string
        code:
          type: string
          enum:
            - DEPOSIT_NOT_RECOVERABLE
            - RECOVERY_UNSUPPORTED
            - SIGNATURE_INVALID
            - VERIFICATION_UNAVAILABLE
            - REFUND_RECONCILIATION_REQUIRED
            - REFUND_FAILED
      required:
        - error
        - code
    ErrorResponse:
      type: object
      properties:
        error:
          type: string
        details:
          type: array
          items:
            type: object
            properties:
              message:
                type: string
              path:
                type: array
                items:
                  anyOf:
                    - type: string
                    - type: number
              code:
                type: string
            required:
              - message
      required:
        - error

````