Swagger API Explorer

Download the canonical Bitnob API v2 OpenAPI 3.0 specification and drop it straight into your code generator, API design tool, or Postman workspace.

Download API Specifications

Two artifacts are published — the JSON spec (best for code generators) and the YAML spec (best for human review and diffs). Both are byte-for-byte equivalent and describe Bitnob API v2 exactly.

OpenAPI 3.0 Specification Files

bitnob-api-v2.openapi.json

OpenAPI 3.0 specification in JSON — feed directly into openapi-generator, Prism, Spectral, or Stoplight

bitnob-api-v2.openapi.yaml

Same spec rendered as YAML — easier to read, review, and diff in pull requests

Quick Downloads

Click either link below to download the spec file directly — both files are served from this site's public/ directory, so no authentication is required.

Download bitnob-api-v2.openapi.json — OpenAPI 3.0 JSON specification
Download bitnob-api-v2.openapi.yaml — OpenAPI 3.0 YAML specification

What's in the spec

Every v2 endpoint: Identity, balances, addresses, transactions, withdrawals, exchange rates, trading, bulk transfers, payouts, cards, lightning, customers, and beneficiaries

Request & response schemas: Full JSON Schema definitions under components/schemas for every payload — fed directly to type-safe client generators

HMAC authentication: The X-Auth-Client, X-Auth-Timestamp, X-Auth-Nonce, and X-Auth-Signature headers are documented as a securityScheme so your generated client knows to prompt for them

RFC 7807 problem responses: Error responses reference a shared Problem schema so your client surfaces correlation_id and detail out of the box

Getting Started

Step 1: Download the spec

Pick a format: bitnob-api-v2.openapi.json for code generators and validators, bitnob-api-v2.openapi.yaml for human review

Grab it: use the Quick Downloads links above, or curl -O the URL directly — no auth required

Verify the version: the spec's info.version is 2.0.0 — if you're still on v1, upgrade before generating clients

Step 2: Import into your tooling

Code generation: openapi-generator-cli generate -i bitnob-api-v2.openapi.yaml -g <language> produces a typed client in 40+ languages

API design tools: Import into Stoplight, Swagger Editor, or Insomnia to browse endpoints and try requests against sandbox

Postman: Prefer the pre-built Postman collection — it ships a pre-request script that auto-signs every call with HMAC-SHA256, which OpenAPI import alone does not wire up

CI contract testing: Feed the spec into Prism, Schemathesis, or Spectral to mock, fuzz, and lint your integration

API Coverage

Our Swagger documentation covers 100% of the Bitnob API surface area.

Core Endpoints

Identity — GET /api/whoami for workspace introspection

Balances — Per-currency workspace balances

Addresses — Deposit address generation across supported chains

Transactions — Paginated transaction history with filters

Withdrawals — On-chain and off-chain withdrawal flows

Exchange rates — Real-time quotes for supported pairs

Trading — Market, scheduled, and target orders

Bulk transfers — CSV/XLSX batch payouts with optional recurrence schedules

Payouts — Single and batch payouts to bank accounts and wallets

Cards — Virtual card issuing, funding, freeze/unfreeze, spend limits, and termination (the only DELETE in v2)

Lightning — Invoices, payments, and node operations

Customers — KYC onboarding and customer lifecycle

Beneficiaries — Saved payout recipients

Integration Workflows

Review the spec: Open bitnob-api-v2.openapi.yaml in Swagger Editor or Stoplight to browse endpoints and data models

Download the spec: Pull bitnob-api-v2.openapi.json (or .yaml) into your repo so your build can regenerate clients deterministically

Generate the client: Run openapi-generator-cli (or your language's preferred generator) to produce a typed SDK

Validate against sandbox: Point your generated client at https://api.bitnob.com with your client_id and the sandbox client_secret, then hit GET /api/whoami as a smoke test

Cut over to production: Swap your sandbox client_secret for the production one — same client_id, same base_url (https://api.bitnob.com) — the same binary talks to both

Spec-driven workflows

Add these to your build pipeline to catch drift early

Contract testing — Run Schemathesis against sandbox to fuzz every endpoint with schema-derived inputs and flag any response that drifts from the spec

Linting — Add Spectral to CI to enforce your internal OpenAPI style rules on generated code

Mocking — Stand up Prism as a local mock server using the spec so frontend and mobile teams aren't blocked on backend availability

Diffing — Track bitnob-api-v2.openapi.json in your repo and run oasdiff on each upgrade to see exactly which endpoints, schemas, and enums changed

Tip

Pro Tip: Download bitnob-api-v2.openapi.yaml and feed it to openapi-generator-cli generate -i bitnob-api-v2.openapi.yaml -g <language> to produce a fully-typed client library. Commit the generated code (or at least the input spec) to your repo so upgrades are a one-line bump.

Note

Environment Safety: Always start with your client_id plus the sandbox client_secret against base_url=https://api.bitnob.com. Production has its own secret key (the client_id is shared across both environments), and the two secrets cannot be used interchangeably — mixing them returns 401 rather than silently moving real funds.