Skip to main content

Affiliates

Affiliate profiles let you register a partner-scoped app-fee recipient with a payout destination on any supported chain under a stable affiliateId, then reference that id in quote requests.

PUT /v1/affiliates/:affiliateId

Create or update an affiliate profile.
Request (EVM USDC payout):
All four fields are required. payoutAddress is where affiliate fee claims are settled, and it is validated against the chosen payoutChain’s address format. Any (chain, asset) tuple in the live payout route table is accepted. Call GET /v1/affiliate-dashboard/payout-destinations for the current set. The server validates the pair on PUT /v1/affiliates/:affiliateId and rejects unsupported combinations with invalid_payout_destination. Lightning is intentionally excluded. Lightning invoices are single-use and amount-bound, so they do not fit a static payout-address model. Response:

GET /v1/affiliates

List affiliate profiles for your partner.
Query params:
  • includeDisabled (true|false, default false)
  • limit (default 200, max 1000)
  • offset (default 0)

DELETE /v1/affiliates/:affiliateId

Disable an affiliate profile.
Response:

POST /v1/affiliates/:affiliateId/claim

Create a claim for the full available affiliate fee balance. The available balance reflects the affiliate’s 80% share after Flashnet’s 20% platform cut. Minimum claim is $1 USDC.
No request body. The claim amount is the full available balance. Response:
Claims require a payout destination configured on the affiliate profile (payoutChain, payoutAsset, payoutAddress). Claims are settled out of the same ledger where the fees accrued and delivered to the configured payout destination. How an order’s fees resolve to a settlement ledger is documented in Fees. Valid payout destinations come from GET /v1/affiliate-dashboard/payout-destinations.

GET /v1/affiliate-dashboard/payout-destinations

List every (chain, asset) tuple supported as a payout destination. The list is derived live from the orchestrator’s pipeline route table, so it stays in sync with backend reality without doc updates whenever new supported chains are added. Use this for discovery instead of GET /v1/orchestration/routes (which only returns user-facing orchestration routes, not payout routes).
Response:
Entries are sorted alphabetically (case-insensitive) by (chain, asset). Lightning is intentionally excluded. The example above is truncated. Call the endpoint for the current canonical set.

GET /v1/affiliates/:affiliateId/claims

List claims for an affiliate.
Query params:
  • limit (default 50, max 200)
  • offset (default 0)

Partner webhooks

Webhooks deliver order status changes for your partner account.

POST /v1/webhooks

Register an endpoint.
Response:
secret is only returned at creation time. Store it.

DELETE /v1/webhooks/:id

Disable an endpoint.
Response:
See Webhooks for signature verification, payload shape, and retry behavior.

Partner fee invoices

Invoice billing is enabled by Flashnet for approved partner-route combinations. Partners cannot opt into it by request. When invoice billing is enabled, the transaction does not deduct the platform fee from the user flow. The billed bps accrue to the partner and can be reviewed from the dashboard API.

GET /v1/partner/dashboard/fee-invoices

Read the partner-scoped fee amount owed, split between uninvoiced accruals and draft or issued invoices.
Query parameters: Response:
All amounts are in the fee asset’s smallest units. totalFeeAmount in totals is pendingAccrualAmount + outstandingInvoiceAmount. Paid and void invoices are excluded from outstanding totals.

Accumulation addresses

Accumulation addresses are reusable deposit addresses on Solana and any supported chain. Each deposit automatically creates an order that delivers BTC or USDB on Spark.

POST /v1/accumulation-addresses

Create an accumulation address. Inline app fee recipients:
Registered affiliates with per-address bps override:
appFees and affiliateIds are both optional and mutually exclusive (use one or the other, not both). affiliateIds entries accept the same string | { affiliateId, feeBps } union shape as POST /v1/orchestration/quote. The fee plan you submit is validated at creation time and frozen onto the address. Every deposit processed through this address replays the same plan without re-evaluating affiliate profiles. See Reusable Addresses for details. Response:
The response appFees array reflects the frozen fee plan. Each entry always has recipient and feeBps. affiliateId is present for entries backed by a registered affiliate profile (the recipient is pulled from the profile’s payoutAddress); inline appFees entries omit affiliateId. The array is omitted from the response when no fee plan was configured at creation.

POST /v1/accumulation-addresses/sync

Re-register your enabled Solana-sourced accumulation addresses into the configured Helius deposit-detection webhooks. Relay-backed addresses (EVM and other non-Solana sources) are not touched; use the per-address reindex endpoint for those.

POST /v1/accumulation-addresses/:idOrAddress/reindex

Ask Relay to rescan one Relay-backed deposit address for missed deposits. :idOrAddress accepts the acu_... id or the reusable deposit address itself. If Relay finds a balance, it queues the sweep and the normal fill-detection path creates the order. Native Solana accumulation addresses return 400; they have no Relay deposit address to rescan.
Like address creation, this endpoint accepts client keys with the accumulation:create scope in addition to server keys.

GET /v1/accumulation-addresses

List accumulation addresses.

GET /v1/accumulation-addresses/:id

Get a single accumulation address, including subscription status.

DELETE /v1/accumulation-addresses/:id

Disable an accumulation address.

Liquidation addresses

Liquidation addresses are reusable Bitcoin L1 deposit addresses. Each deposit automatically creates an order that delivers to any supported chain and asset.

POST /v1/liquidation-addresses

Create a liquidation address. Inline app fee recipients:
Registered affiliates with per-address bps override:
appFees and affiliateIds are both optional and mutually exclusive. affiliateIds entries accept the same string | { affiliateId, feeBps } union shape as POST /v1/orchestration/quote. The fee plan is frozen at creation time and replayed into every Bitcoin L1 deposit processed through the address. appFees inline recipients must be valid addresses on the fee settlement chain (Solana USDC for most routes, Spark USDB for USDB destinations), not the destination chain. See Reusable Addresses for details. Response:
The response appFees array reflects the frozen fee plan. Each entry always has recipient and feeBps. affiliateId is present for entries backed by a registered affiliate profile; inline appFees entries omit it. The array is omitted when no fee plan was configured.

GET /v1/liquidation-addresses

List enabled liquidation addresses.

GET /v1/liquidation-addresses/:id

Get a single liquidation address (enabled or disabled).

GET /v1/liquidation-addresses/orders

List the orders for a liquidation address. Provide exactly one of id or label; sending both, neither, or an empty label returns 400. An unknown or non-owned id returns 404; a label matching none of your addresses returns an empty list. label matches every address you own with that exact label (labels are not unique).
Query params:
  • id: a single liquidation address id (exactly one of id / label is required)
  • label: every liquidation address you own with this exact label
  • status (optional): filter to one order status; paused orders are hidden unless status=paused
  • limit (default 50, max 200)
  • offset (default 0)
Returns { orders, nextOffset }. Each order matches the GET /v1/orchestration/status order shape, including terminal (completed, failed, refunded) orders. Requires a server key; client keys are rejected.

DELETE /v1/liquidation-addresses/:id

Disable a liquidation address.

POST /v1/liquidation-addresses/sync-blockdaemon

Synchronize enabled liquidation addresses into Blockdaemon Streaming watchlists.
Pay links are durable payment links. Each click on the public /pay/:shortId URL creates a fresh Lightning order delivered to the link’s recipient. All pay-link endpoints require a server key (fn_...); client keys are rejected. See Pay Links for the product flow and frontend integration.

POST /v1/pay-links

Create a pay link.
Request body: Exactly one of amountOut or amountFiatUsd must be set. Response (201):
Exactly one of amountOut or amountFiatUsd is set on every link; the other is null. shortUrl is the shareable payment URL. List pay links for your partner. Returns { "payLinks": [...] } with the same per-link shape as create.
Query params:
  • includeDisabled (true|false, default false)
  • limit (default 200, max 1000)
  • offset (default 0)

GET /v1/pay-links/:id

Get a single pay link by pl_... id. Returns 404 when the link does not exist or belongs to another partner.

DELETE /v1/pay-links/:id

Disable a pay link (soft delete). The public URL returns 404 afterward; orders created before disabling continue to process.
Response: