Developer documentation

SEND for developers.

The same rules the product runs on, written for people reading code. Prose lives in the main docs; this page is the reference with examples.

Concepts

A creator is an identity, not a wallet. Socials attach to a creator record; a launch attaches a coin to that creator; fee events attach money to the coin's mint; a claim proves ownership of the social and releases the money.

model

creator        # stable record, survives handle changes
 └─ social     # platform + username (x, tiktok, youtube, …)
 └─ launch     # one coin, one mint, one creator
     └─ fee event   # one on-chain trade fee, keyed by signature + vault
         └─ ledger  # 90 / 5 / 5 split in integer lamports
             └─ claim → payout → confirmed receipt

Fee math

Splits are computed in integer lamports, never floating point SOL. The creator receives the remainder, so the three parts always sum exactly to the fee.

split (lamports, integer)

const sendCut    = (fee * 5n) / 100n;
const buybackCut = (fee * 5n) / 100n;
const creatorCut = fee - sendCut - buybackCut; // remainder → creator

// 5_925_930 lamports →
// creator 5_333_342 · send 296_294 · buyback 296_294

Display uses exact conversion; amounts are shown in SOL with no rounding of audit figures.

State machines

No state is advanced by the browser and none is advanced optimistically. Money states change only after a Solana transaction reaches confirmation.

launch

DRAFT → PAYMENT_PENDING → PAYMENT_CONFIRMED
      → LAUNCH_SUBMITTED → LAUNCH_CONFIRMED → COMPLETE
                         ↘ FAILED → REFUNDED

creator balance

EARNED     # fee generated and attributed on-chain
AVAILABLE  # claimable by the verified creator
SENDING    # payout transaction submitted
SENT       # payout confirmed on Solana — never set before confirmation

buyback

ALLOCATED → PURCHASED → BURN CONFIRMED

Public endpoints

These require no credentials, are read-only, and return no personal data. Everything else in the product runs through authenticated server functions, not a public API.

GET /api/public/ping — uptime probe

curl -s https://sendonx.com/api/public/ping

{ "ok": true, "service": "pay",
  "checks": { "site": true, "admin": true },
  "time": "2026-09-17T13:40:00.000Z" }
# 200 when healthy, 503 otherwise

GET /api/public/avatar/:platform/:handle — creator image

<img src="https://sendonx.com/api/public/avatar/x/sendmoneycash_" alt="" />
# returns an image, cached 24h, always falls back to a generated
# avatar instead of failing. 6s total budget per request.

GET /api/public/coin-image/:id — coin artwork

curl -s -o coin.png https://sendonx.com/api/public/coin-image/<launch_id>

Automation endpoints

Scheduled work (fee indexing, launch recovery, payout sweeps, buyback and burn confirmation) is exposed as POST endpoints that require a shared cron secret. They are idempotent: repeating a call never repeats a payment.

POST /api/public/auto-run

curl -X POST https://sendonx.com/api/public/auto-run \
  -H "Authorization: Bearer $SEND_CRON_SECRET"

# unauthenticated → 401, no work performed
# each operation carries its own idempotency key

The secret is held server-side only and is never exposed to the browser. Public credentials and an SDK are not released yet.

On-chain references

Everything financial is verifiable independently. The $SEND mint is defined once in the codebase and every reference in the product reads from that single source.

constants

SEND mint  2XuQnYQ1q3oTjPL9j4PfhV1AEqcZ6Hq2PzPzuxaASEND
launch fee 30_000_000 lamports (0.03 SOL), direct transfer only
venue      pump.fun
splits     90 / 5 / 5 (creator / SEND / buyback)

verify a payout yourself

curl -s https://api.mainnet-beta.solana.com -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getTransaction",
       "params":["<signature>",{"maxSupportedTransactionVersion":0}]}'

Errors and rate limits

Every money operation fails on its own without affecting other users. Rejections preserve their records and return a reason; nothing is silently retried in a way that could pay twice.

rate limiting

HTTP 429
Retry-After: <seconds>

# applies to creator search, launch submission, claim start,
# and verification. Confirmation, reconciliation and automation
# are exempt so retries can never strand money mid-flight.

failure shape

{ "error": "payment intent already consumed",
  "operation": "launch",
  "requestId": "…" }
# a rejected operation moves no funds and keeps its audit record

Looking for the product explanation instead? Read the documentation or the infrastructure overview.