Platform developer console
Pick an account under Accounts (Use) to set the session context for wallet APIs, backoffice transaction filters, and swaps. Grant permissions once under Services Health if you hit “permission denied”. Open the ⌗ Log drawer (bottom-right) to debug API calls.
Quick Lookup
Create Account
Get / Create Deposit Address
POST /api/wallet/deposits/address
List Deposit Addresses
GET /api/wallet/deposits/addresses
List Deposits GET /api/wallet/deposits
Get Deposit by ID GET /api/wallet/deposits/{id}
List Withdrawals GET /api/wallet/withdrawals
Get Withdrawal by ID
GET /api/wallet/withdrawals/{id}
Withdrawal trace across services/databases
End-to-end evidence for one withdrawal: wallet record, Fireblocks history, transaction-service records, ledger entries, ledger balances, and account balances.
Rolling 24 hours, same as
ensure_withdrawal_limit in wallet-service: statuses
pending_approval → completed count toward the cap (failed /
cancelled / rejected do not). Spent is the sum of usdt_cost (Binance
USDT-equivalent notional — same numeric scale as a USD daily cap for
stable pricing; not a different “currency” from USD). The daily cap is read from
WITHDRAWAL_DAILY_LIMIT_USDT or WITHDRAWAL_DAILY_LIMIT_USD (must
match wallet-service; if unset, 1000 — same as lib-limits).
Withdrawal limit usage
GET /api/withdrawal-limit-usage
List Swaps GET /api/wallet/swaps
Create Swap POST /api/wallet/swaps
Get Swap Quote GET /api/wallet/swaps/quote
Binance Orders GET /api/swap/orders
Ledger Entries GET /api/ledger
Shows one row per (account, coin, reserve) that has ledger entries.
Leave filter empty to include every account (e.g. operational
00000000…).
Transaction service — transactions table
Direct read from the transaction-service Postgres database (same rows the service
persists). Use TRANSACTION_DATABASE_URL if your DB name differs from
transaction_service.
transactions.Project databases — tables and columns
Full schema read from configured backoffice DB connections. Column names are shown exactly as they exist in Postgres (no display formatting).
Table data preview for testing
Load sample rows from any table using its real identifier names. This helps verify migrations and data shape quickly during manual testing.
List Coins GET /api/coin/list
Get Coin GET /api/coin/get
Resolve Coin ID GET /api/coin/resolve
Resolve by Slug GET /api/coin/resolve-by-slug
Admin: Save Coin (Create or Update) POST /api/coin/admin/update
Uses name + network as key: updates existing coin when found, creates a new one when not found.
Optional fields (expand)
Create Withdrawal POST /api/wallet/withdrawals
Fireblocks vault withdrawals are sourced from this vault. Ledger ffffffff…ffff is the treasury ledger mirror.
On-chain address optional: set BACKOFFICE_TREASURY_DEPOSIT_ADDRESS in
backoffice env (same process as FIREBLOCKS_TREASURY_VAULT_ID).
Company aggregate custody (debit-normal). Withdrawal balance checks use this ledger account.
Get Withdrawal Quote
GET /api/wallet/withdrawals/quote
Fireblocks webhook log
Rows come from webhook_events in the
wallet-service database — every payload received on
POST /webhooks/fireblocks is stored for audit and replay (see
wallet-service persist_webhook_event).
User Management
Create passwordless users, list existing users, and manage MFA via user-service (port 50058). Dev creation uses the OTP bypass token.
Create Passwordless User
User Actions
User List (from DB)
Account Management (Admin)
BackofficeAccountService (account-service :50052) — list, inspect, lock/suspend/reset PIN on accounts.
List Accounts
Account Actions
Reset PIN
Special Accounts
All Transactions (Backoffice)
BackofficeTransactionService — list, review, approve, cancel transactions. Review/Approve/Cancel require OTP (use "000000" in dev).
Account Transactions
Review Transaction
Approve Transaction
Cancel Transaction
Treasury & Operational
Treasury Transactions
Requires dev operator permissions. If you get "permission denied", go to and click "Grant All Permissions to Dev Operator".
Operational Transactions
BCR Institutions (config-service)
BCR participant banks for LBTR. config-service port 50060.
Create Institution
Get / Update Institution
Services Health
Live TCP + DB pool check for every service. Auto-refreshes every 15 s.
gRPC Services
Databases
Infrastructure
Dev Operator Permissions
Grant all backoffice permissions to the dev operator (00000000-0000-0000-0000-000000000001).
Required to access Treasury, Operational, and other permission-gated endpoints.
Safe to run multiple times — auth-service is idempotent on grants.
LBTR / BCR Mock Producer
Injects messages into Kafka to simulate the BCR network. transaction-service consumes lbtr.transfer.received and creates transactions.
Kafka broker: localhost:9093
· BCR REST mock: http://127.0.0.1:8088/api/bcr
① Inject Incoming Transfer (BCR → us)
Publishes to lbtr.transfer.received. transaction-service creates a new transaction and credits the account.
② Inject Status Update (BCR → us)
Publishes to lbtr.status.incoming. Simulates BCR confirming or returning a transaction.
Quick Scenarios
③ Track Resulting Transaction & All State Changes
After injecting a transfer, see the created transaction, its status progression, ledger entries (debit/credit), and account balance changes. Auto-refreshes on status inject.
④ BCR Gateway — Outgoing Instructions Received
When lbtr-service processes an outgoing payment (e.g. a LBTR transfer our users send), it calls the BCR Java gateway at
POST /api/lbtr/instrucciones. In dev, the backoffice mocks that gateway — all instructions land here.
Transfer365 Mock Producer
Injects messages into Kafka to simulate the Transfer365 network. transaction-service consumes transfer365.received and creates transactions.
Kafka broker: localhost:9093
Inject Received Transfer (transfer365.received)
Simulates Transfer365 sending an incoming payment. transaction-service will process and credit the account.
Inject Status Update (transfer365.received.status)
Updates the transaction status in transaction-service via Kafka.
transfer365-service will log an error for mock-injected transactions because they bypass its internal file engine (redb has no record). This is harmless — transaction-service correctly processes the status update.
Quick Scenarios
③ Track Resulting Transaction & All State Changes
After injecting a transfer above, see the transaction created, its current status, ledger entries, and account balance. Auto-refreshes when you inject a status update.
Transfer365 File Gateway Simulator
DEV ONLY
Simulates the BCR gateway side so you can test transfer365-service end-to-end locally.
Real services are used — the full stack runs (Kafka, ledger, transactions, balances).
Requires T365_APP_DIR = same path as transfer365-service's APP_DIR (default /tmp/transfer365).
⚡ After inject, the browser auto-polls every 400ms for 5s then 1.5s for 15s to show file movements in real time.
② File Browser
③ T365 Service Logs
— transfer365-service log (last 200 lines, today)④ File Flow Steps
file drop → T365 engine → Kafka → tx-service → ledger → ACK. Auto-starts on inject or trace click.
—
⑤ Flow Tracer — Transaction · Ledger · Balance
Auto-fills after pacs.008 inject. Tracks the full downstream chain: file written → Kafka event → transaction created → ledger credited → balance updated
BCR Gateway Mock
This backoffice replaces the external Java lbtr-gateway app.
lbtr-service calls POST /api/bcr/lbtr/instrucciones here when processing outgoing payments.
Click ↓ JSON on any row to download the exact payload sent to the gateway.
BCR Test Environment Reference (from docs/BCR_CONTEXT.md — for lbtr-gateway Java app, not this mock)
SOAP Endpoints (test)
| Instrucciones | lbtrdes.bcr.gob.sv/lbtr-ws/InstruccionServiceSoapHttpPort |
| Lote | lbtrdes.bcr.gob.sv/lbtr-ws/LoteServiceSoapHttpPort |
| SPM (T365) | lbtrdes.bcr.gob.sv/lbtr-ws/ServicioPagoServiceSoapHttpPort |
| Server IP | 192.168.11.56 |
| Notif server | notificacioneslbtrdes.bcr.gob.sv (192.168.11.69) |
⚠ BCR internal network only — VPN / dedicated line required
WS-Security & Certificates
| Protocol | SOAP/WSDL Document/Wrapped |
| Security | OASIS WS-Security V1.2 · X.509 |
| Policy | Wssp1.2-2007-Wss1.1-X509-Basic256Sha256 |
| Keystore | lbtrcliente.jks (pw: lbtrcliente) |
| Truststore | lbtrcliente_truststore.jks |
| Key alias | lbtrcliente |
TraceableReference format (25 chars)
YYYYMMDD{entity:03}{correlative:05}{internal_ref:09}
Entity 089 = our participant. Date must match today — BCR rejects mismatches.
Auto-generated in LBTR mock above. Implemented in lib-bcr::lbtr::types::TraceableReference.
Full specs → docs/BCR_CONTEXT.md in repo · Also see dev/console/TEAM_REVIEW_BACKLOG.md §8