Send app API integration services (non-custodial wallet, OpenFinance)

Deliverables checklist

• OpenAPI 3.1 / Swagger specification covering profile, transactions, swap and rewards endpoints
• Protocol analysis report (mobile traffic capture, EIP-4361 signature flow, request signing scheme)
• Runnable reference servers in Python (FastAPI) and Node.js (NestJS) with worked-end-to-end tests
• Indexer worker that watches the on-chain addresses behind a Send handle and normalizes events
• Compliance pack: consent log template, data-minimization checklist, MiCA / FinCEN alignment notes

Typical integration scenarios

1. Creator payouts & tax reports. Resolve a Send link, pull the last twelve months of inbound transfers, classify by token, and generate a year-end statement for accountants. Maps directly to OpenData "transaction export".
2. Treasury reconciliation for a startup. A founder uses Send for vendor payouts. We expose a hosted endpoint that ingests their wallet's transaction stream and pushes normalized rows into Xero or QuickBooks. This is OpenFinance "statement sync" applied to self-custody.
3. Embedded swap inside a partner app. Use the KyberSwap-aggregated quote endpoint to power an in-app token swap, while attaching the resulting receipt to a user's Send profile. Fees can be customized in the underlying KyberSwap call.
4. Loyalty & referral analytics. Pull the referral ledger and Save reward accruals so a growth team can attribute on-chain rewards to specific marketing campaigns — closing the loop between Web3 activity and CRM.
5. KYC / risk overlay for B2B onboarding. Combine the public Send handle, on-chain transaction graph, and a third-party risk scorer to onboard merchants who want to accept Send payments without taking custody themselves.

Technical implementation snippets

Three representative endpoints. Auth uses Sign-In with Ethereum (EIP-4361) and a short-lived bearer token; nothing in this design requires custody of user keys.

// 1. Resolve a Send handle to its public profile
GET /api/v1/send/profile?handle=alice
Authorization: Bearer <ACCESS_TOKEN>

200 OK
{
  "handle": "alice",
  "address": "0xab12...c0de",
  "display_name": "Alice",
  "bio": "freelance designer",
  "avatar_url": "https://cdn.send.app/u/alice.png",
  "links": [
    {"label":"website","url":"https://alice.example"},
    {"label":"x","url":"https://x.com/alice"}
  ],
  "supported_chains": ["ethereum","base","optimism"]
}

// 2. Export transaction statement for a wallet
POST /api/v1/send/statement
Content-Type: application/json
Authorization: Bearer <ACCESS_TOKEN>

{
  "address": "0xab12...c0de",
  "chains": ["ethereum","base"],
  "from_date": "2026-01-01",
  "to_date":   "2026-04-30",
  "include":   ["transfers","swaps","rewards"],
  "format":    "json"
}

// streamed back as paginated JSON, with cursors
{
  "items": [
    {"hash":"0x91...","kind":"transfer","token":"USDC","amount":"125.00","ts":"2026-04-12T08:14:00Z"},
    {"hash":"0xa2...","kind":"swap","src":"USDC","dst":"ETH","src_amount":"500","dst_amount":"0.187","ts":"2026-04-15T11:02:00Z"}
  ],
  "next_cursor": "eyJwYWdlIjoyfQ"
}

// 3. Build a swap via the KyberSwap aggregator
GET /api/v1/send/swap/quote
  ?chain=base
  &tokenIn=0xA0b86...USDC
  &tokenOut=0x4200...WETH
  &amountIn=1000000000
  &userAddress=0xab12...c0de

200 OK
{
  "router": "0x6131B...",
  "amountOut": "374821374000000",
  "route": [{"dex":"UniswapV3","pool":"0x..."},{"dex":"SushiV2","pool":"0x..."}],
  "calldata": "0x12aa3caf...",
  "gasEstimate": 215000,
  "feeBps": 25
}

// Errors are returned as { "error": { "code": "INSUFFICIENT_LIQUIDITY", "message": "..." } }
// 401 / 403 for auth; 429 for rate limit; 5xx forwarded with a correlation id.

Compliance & privacy

Send Inc. does not custody user funds, but any party that builds an API surface around a wallet still touches identifiers and transaction metadata that are regulated as personal data and, in some jurisdictions, as crypto-asset service activity. Our default posture is to align with the EU's Markets in Crypto-Assets (MiCA) regulation — the CASP rulebook came fully into force on 30 December 2024, with member-state transitional windows extending into mid-2026 — and with FinCEN money-services-business guidance for US-facing flows. GDPR and the FCA's UK financial-promotions regime for crypto are also factored in for clients targeting those regions.

Practically, that means every endpoint we ship comes with a documented purpose, a scoped set of data fields, an explicit consent log, retention defaults, and a kill-switch the integrator's compliance officer can flip without redeploying.

Data flow / architecture

A typical Send-app integration follows four nodes:

1. Client app / wallet: issues a SIWE signature; never shares its private key.
2. Ingestion layer: our API gateway validates the signature, exchanges it for a short-lived bearer token, and routes to the correct service (profile, statement, swap, rewards).
3. Indexer / storage: a chain-watcher normalizes raw blocks for the supported networks (Ethereum, Base, Optimism, etc.) into a Postgres + columnar warehouse pair, with PII separated from on-chain facts.
4. Output: JSON / CSV / PDF over REST, plus webhooks for tx confirmations and rewards events. BI tools consume the warehouse directly; downstream apps consume REST.

About us

OpenFinance Lab is an independent studio focused on mobile fintech, Web3, and OpenData / OpenBanking integration. Our engineers come out of payment processors, exchange backends, mobile reverse-engineering, and cloud platforms, and we ship end-to-end financial APIs under real security and compliance constraints rather than slideware.

• Wallets, on/off-ramps, swap aggregators, and DeFi yield reporting
• Mobile traffic capture, EIP-4361 SIWE flows, and signed-request schemes
• Custom Python / Node.js / Go SDKs, OpenAPI specs, and Postman collections
• Two engagement models: source-code delivery from $300 (pay after delivery upon satisfaction) or pay-per-call on our hosted endpoints with no upfront cost

Contact

To request a quote, send us the target app and concrete data you need (e.g. "transaction export for two wallets, JSON, daily refresh, MiCA-friendly"). We typically reply within one business day.

Contact page

Engagement workflow

1. Scope confirmation: which Send surfaces (profile, statement, swap, rewards), which chains, which output formats.
2. Protocol analysis and API design: 2 to 5 business days, complexity-dependent.
3. Build and internal validation against testnets and a staging Send handle: 3 to 8 business days.
4. Documentation, sample clients, and test cases: 1 to 2 business days.
5. Typical first delivery: 5 to 15 business days. Multi-chain indexer or full reward-engine reconciliation may extend this.

FAQ

What data can be exported from a Send app account?

How do you handle authentication for a non-custodial wallet?

How long does delivery take?

How do you handle compliance for a crypto wallet integration?