Sila Wallets API

openapi: 3.0.3
info:
  title: Sila Money Accounts Wallets API
  description: 'Sila is an embedded-finance / banking-as-a-service money API for fintech developers. This OpenAPI document models the documented, live Sila REST surface at https://api.silamoney.com/0.2 (sandbox https://sandbox.silamoney.com/0.2). Every endpoint is invoked with HTTP POST and a JSON message body. Requests are authenticated with ECDSA (secp256k1) signatures computed over a Keccak-256 (SHA3) hash of the stringified message body and passed in the "authsignature" header (app keypair) and, for user-scoped calls, the "usersignature" header (user keypair); KYB / business calls additionally use a "businesssignature" header.

    HONESTY NOTE: Endpoint PATHS and HTTP methods below are grounded in the live Sila docs and live probes. Request and response SCHEMAS are intentionally modeled as permissive objects (additionalProperties: true) rather than reproduced field-by-field - Sila''s real request/response bodies are richer than modeled here. Treat schema bodies as MODELED, not authoritative; consult the linked ReadMe docs for exact fields. The dedicated Virtual Accounts management endpoints are NOT modeled because their exact paths were not confirmed on the pages reviewed.'
  version: '0.2'
  contact:
    name: Sila Money
    url: https://www.silamoney.com/
  x-status: live
  x-reviewed: '2026-07-12'
servers:
- url: https://api.silamoney.com/0.2
  description: Production
- url: https://sandbox.silamoney.com/0.2
  description: Sandbox
security:
- authsignature: []
tags:
- name: Wallets
  description: ECDSA keypair (wallet) registration and management.
paths:
  /register_wallet:
    post:
      operationId: registerWallet
      tags:
      - Wallets
      summary: Register a wallet keypair
      description: Registers an additional ECDSA (secp256k1) keypair / address to a user so it can sign user-scoped requests. Requires authsignature and usersignature.
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Message'
      responses:
        '200':
          description: Wallet registered.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/SilaResponse'
        '400':
          $ref: '#/components/responses/BadRequest'
  /get_wallet:
    post:
      operationId: getWallet
      tags:
      - Wallets
      summary: Get the signing wallet
      description: Returns details for the wallet whose keypair signed the request. Requires authsignature and usersignature.
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Message'
      responses:
        '200':
          description: Wallet details.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/SilaResponse'
        '400':
          $ref: '#/components/responses/BadRequest'
  /get_wallets:
    post:
      operationId: getWallets
      tags:
      - Wallets
      summary: List wallets
      description: Lists all wallets (keypairs) registered to a user. Requires authsignature and usersignature.
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Message'
      responses:
        '200':
          description: List of wallets.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/SilaResponse'
        '400':
          $ref: '#/components/responses/BadRequest'
components:
  responses:
    BadRequest:
      description: 'Bad request - missing / invalid signature header or failed validation. Live example body - {"success": false, "validation_details": {"header": "This field is required."}, "message": "Bad request.", "status": "FAILURE"}.'
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/SilaResponse'
  schemas:
    SilaResponse:
      type: object
      description: MODELED. Common Sila response envelope. success / status indicate outcome; message is human-readable; validation_details carries field errors on 400. Endpoint-specific fields are returned alongside and are not exhaustively modeled.
      additionalProperties: true
      properties:
        success:
          type: boolean
        status:
          type: string
          description: SUCCESS or FAILURE.
        message:
          type: string
        reference:
          type: string
        validation_details:
          type: object
          additionalProperties: true
    Message:
      type: object
      description: MODELED. Sila message body. Every request carries a header object with the app handle, an optional user handle, a per-request reference, and a created (epoch) timestamp, plus endpoint-specific fields. Real bodies are richer than modeled here - see the linked docs.
      additionalProperties: true
      properties:
        header:
          type: object
          additionalProperties: true
          properties:
            created:
              type: integer
              description: Unix epoch timestamp of request creation.
            app_handle:
              type: string
              description: The registered application handle.
            user_handle:
              type: string
              description: The end-user or business handle (user-scoped calls).
            reference:
              type: string
              description: Client-supplied request reference / idempotency aid.
  securitySchemes:
    authsignature:
      type: apiKey
      in: header
      name: authsignature
      description: Hex-encoded ECDSA (secp256k1) signature of the Keccak-256 hash of the stringified JSON message body, signed with the app's private key. User- scoped endpoints additionally require a "usersignature" header (user keypair); KYB / business endpoints additionally require a "businesssignature" header (business keypair). These are additional headers rather than separate OpenAPI security schemes because OpenAPI apiKey schemes cannot express "sign this exact body."