LOBSTR Vault API integration services (Stellar multisig / OpenFinance)

1 · Pending-transaction relay API

Mirrors the in-app queue: when a wallet such as LOBSTR, StellarX or StellarPort posts a transaction for a Vault-protected account, your backend receives the signed XDR, decoded operations, source account, memo, fee and required-signers list. Concrete use: a treasury approval board that shows "3 transactions waiting, 2 of 3 signatures collected".

2 · Signer-set & threshold verification

Reads account.signers from Horizon, classifies each signer (master key, additional ed25519 keys, the well-known Vault co-signer), and reports weights against low/medium/high thresholds. Concrete use: a compliance check that flags any monitored account whose master-key weight is still non-zero, i.e. not yet truly multisig.

3 · Signed-XDR submission & result tracking

Wraps the Vault transactions endpoint (POST a transaction envelope XDR) and Horizon's POST /transactions for the final broadcast, returning the transaction hash, ledger, and success/result codes. Concrete use: a payout service that submits a co-signed batch and stores the resulting hashes for audit.

4 · Statement & balance export

Pulls /accounts/{id}/transactions, /operations, /effects and balances with cursor paging and date filters, then renders CSV, JSON or PDF statements per account or per asset. Concrete use: month-end reconciliation of XLM and issued-token movement against an internal ledger.

5 · Push-notification fan-out

Re-emits the "new transaction request" event LOBSTR Vault shows on the signer device as a webhook or message-queue event for your systems (Slack, PagerDuty, an internal bot). Concrete use: alerting an operations team within seconds of a high-value transfer entering the approval queue.

6 · Vault Signer Card (NFC) flow notes

Documents the Tangem-built Signer Card path — the chip creates and holds an uncopyable signer account; a tap over NFC produces a signed transaction. Concrete use: a 2-of-3 setup where a card is the offline backup signer, plus runbook copy for your support team.

A · Corporate treasury approval board

Context: a company holds operating funds on a Stellar account secured 2-of-3 with LOBSTR Vault. Finance wants a web board, not three phones. Data/API: pending-transaction relay (XDR + decoded ops, signature progress) plus the Vault submission endpoint once enough approvals exist. OpenFinance mapping: the board is a consent-scoped "read your queued payments" surface, mirroring an Open Banking payment-initiation review screen — but the actual authorization stays on each signer's device.

B · Exchange / custodian listing check

Context: a venue must confirm a customer's Stellar account is genuinely under multisig before raising withdrawal limits. Data/API: Horizon GET /accounts/{id} → inspect signers for the documented Vault co-signer public key and confirm master-key weight is zero. OpenFinance mapping: equivalent to an account-information "control verification" call before extending services.

C · Accounting & tax reconciliation

Context: month-end close needs every XLM and issued-token movement reconciled to an ERP ledger. Data/API: statement export over /accounts/{id}/transactions, /operations, /effects with cursor paging; output CSV/JSON keyed by paging_token. OpenFinance mapping: a classic account-aggregation / statement-feed pattern applied to an on-chain account.

D · Real-time payout pipeline

Context: a payments product builds transactions in its backend, needs co-signature from a Vault-held key, then broadcasts. Data/API: build envelope → POST XDR to the Vault transactions endpoint → wait for the co-signature webhook → submit to Horizon POST /transactions → record hash and result codes. OpenFinance mapping: payment initiation with strong customer authentication, where the "second factor" is the multisig signer.

E · DAO / multi-party governance log

Context: a DAO runs an n-of-m treasury and wants a public, tamper-evident log of who approved what. Data/API: pending-transaction relay + submission results, written to an append-only store and surfaced on a status page. OpenFinance mapping: transparent transaction-history sharing with explicit member consent — open data in the literal sense.

1 · Verify an account is Vault-protected (Horizon, read-only)

GET https://horizon.stellar.org/accounts/GABC...XYZ
Accept: application/json

// 200 OK (trimmed)
{
  "account_id": "GABC...XYZ",
  "thresholds": { "low_threshold": 10, "med_threshold": 20, "high_threshold": 20 },
  "signers": [
    { "key": "GABC...XYZ", "weight": 0,  "type": "ed25519_public_key" },   // master disabled
    { "key": "GA2T6GR7...PROTECTEDBYLOBSTRVAULT", "weight": 10, "type": "ed25519_public_key" },
    { "key": "GDEVICE...2NDKEY", "weight": 10, "type": "ed25519_public_key" }
  ],
  "balances": [ { "asset_type": "native", "balance": "1042.5000000" } ]
}
// Logic: master weight 0 + Vault co-signer present + weight sum >= high_threshold => multisig OK

2 · Submit a transaction for Vault co-signature

POST https://vault.lobstr.co/api/transactions/
Content-Type: application/json

{ "xdr": "AAAAAgAAAAB...<base64 TransactionEnvelope>..." }

// Accepted -> the signer device shows a push notification.
// If "reject unsigned" protection is enabled and the XDR carries no valid
// signature, the API returns an error instead of queuing it:
//   400 { "error": "transaction must contain at least one valid signature" }

// After the signer approves, your webhook (module 1/5) fires:
{ "event": "transaction.signed",
  "tx_hash": "9f1c...e7", "account_id": "GABC...XYZ",
  "signers_collected": 2, "signers_required": 2, "signed_xdr": "AAAAAg...==" }

3 · Pull a statement page (Horizon, paged)

GET https://horizon.stellar.org/accounts/GABC...XYZ/transactions?limit=50&order=desc&cursor=

// 200 OK -> _embedded.records[]: { id, hash, ledger, created_at,
//   source_account, fee_charged, memo, operation_count, paging_token }
// Loop on paging_token until _embedded.records is empty,
// then map each record to a CSV/JSON statement row. Wrap 429/5xx
// with exponential backoff; Horizon rate-limits per IP.

4 · Backend auth for our hosted API (pay-per-call mode)

POST https://api.openfinance-lab.com/v1/auth/token
Content-Type: application/json
{ "client_id": "...", "client_secret": "...", "scope": "vault.read vault.submit" }

// 200 OK { "access_token": "eyJ...", "expires_in": 3600, "token_type": "Bearer" }

GET https://api.openfinance-lab.com/v1/lobstr-vault/accounts/GABC.../pending
Authorization: Bearer eyJ...
// 200 OK { "pending": [ { "tx_hash": "...", "operations": [...],
//   "signers_collected": 1, "signers_required": 2 } ] }
// Errors: 401 invalid_token · 403 scope_missing · 404 account_not_monitored · 429 rate_limited

Compliance & privacy

We operate only under your authorization or via documented public Stellar APIs, and we never request, transmit, or store private keys — that is the whole point of LOBSTR Vault's local key storage. Relevant frameworks we design against include the EU Markets in Crypto-Assets Regulation (MiCA) for crypto-asset service providers, the FATF "Travel Rule" for VASP transfers, and GDPR-style data minimization and retention limits. Integrations ship with consent records, scoped access tokens, and an audit log of every read and submission. Where you act as a regulated entity, we align deliverables with your existing AML/KYC and record-keeping obligations.

Standards & building blocks

• Stellar Horizon API — accounts, signers, thresholds, transactions, operations, effects
• Stellar Ecosystem Proposals — SEP-7 transaction URIs, SEP-10 web auth, SEP-30 recoverable accounts
• LOBSTR Vault transaction-submission flow (signed XDR) — open source, GNU GPL v3.0
• account.signers verification pattern already used by StellarTerm, StellarX, LOBSTR and Stellarport
• Tangem-built Vault Signer Card (NFC) — offline / backup co-signer documentation

Deliverables checklist

• API specification (OpenAPI / Swagger) for the pending-transaction, verification, submission and statement endpoints
• Protocol & flow report: how the Vault app queues, signs and submits transactions; Horizon endpoints used; Signer Card NFC path
• Runnable source for the connector and sample integration (Python and Node.js), with config for mainnet and test network
• Webhook receiver sample + retry/idempotency handling for transaction.signed events
• Automated tests, Postman/HTTP collection, and end-user-style API documentation
• Compliance notes: consent records, retention defaults, MiCA / FATF Travel Rule alignment, key-handling policy (we hold none)

Engagement workflow

1. Scope confirmation: accounts/signers in scope, data needed (pending tx, signer sets, history, balances), mainnet vs. testnet.
2. Protocol analysis & API design (2–5 business days, complexity-dependent).
3. Build & internal validation against Horizon and a test signer (3–8 business days).
4. Docs, samples, test cases (1–2 business days).
5. Typical first delivery: 5–15 business days; third-party approvals or hardware (Signer Card) logistics may extend timelines.

About us

We are an independent technical service studio focused on App interface integration, authorized API integration, and open-data work in fintech and crypto. Our engineers come from payment gateways, digital banks, blockchain infrastructure, and protocol-analysis backgrounds, and we ship end-to-end deliverables — from reverse engineering and protocol analysis to runnable source code, documentation and test plans — under clear security and compliance constraints.

• Stellar/Horizon connectors, multisig orchestration, and on-chain statement pipelines
• OpenData / OpenFinance / OpenBanking-style consent and audit design adapted for self-custody
• Custom Python / Node.js / Go SDKs, webhook receivers, and test harnesses
• Full pipeline: protocol analysis → build → validation → compliance review
• Source code delivery from $300 — you receive runnable API source code and full documentation; pay after delivery upon satisfaction
• Pay-per-call API billing — call our hosted endpoints and pay only per call, no upfront cost; ideal for teams that prefer usage-based pricing

Contact

For a quote, or to submit your target app and requirements (the Stellar accounts/signers in scope and the data you need), open our contact page:

Contact page

Reference: app "LOBSTR Vault. Multi-signature" · package com.lobstr.stellar.vault. We will confirm scope, authorization and timelines before any work begins.

What do you need from me to start a LOBSTR Vault integration?

The target app name (provided), the Stellar accounts or signer public keys in scope, the data you want (pending transactions, signer sets, transaction history, balances), and any sandbox or test-network credentials. We work only under your authorization or with documented public Stellar/Horizon APIs.

How long does delivery take?

Usually 5 to 12 business days for a first API drop with documentation. A read-only Horizon and account.signers monitor is faster; full pending-transaction webhook plus XDR submission and statement export pipelines take longer.

How do you handle compliance and key safety?

We never request or store private keys. Signing stays on the Vault app or the Tangem-built Vault Signer Card. We follow GDPR-style data minimization, keep consent and audit logs, align with the FATF Travel Rule and the EU MiCA regime for crypto-asset service providers, and sign NDAs when required.

Is LOBSTR Vault open source, and can you build on it directly?

Yes. LOBSTR Vault is released under the GNU GPL v3.0 with public Android and iOS repositories, so we can reference the official transaction-submission flow (the Vault transactions endpoint that accepts a signed XDR) and the account.signers verification pattern already used by StellarTerm, StellarX, LOBSTR and Stellarport.