marketplace

POST /v1/marketplace/vendor/payout-methods

Propose a destination to be paid at.

Alle marketplace Endpunkte

Authentifizierung

Senden Sie einen API-Schlüssel als Bearer-Token. Dieser Endpunkt gibt in der Spezifikation keine spezifische Berechtigung an. Versehen Sie Ihren Schlüssel daher mit den minimal erforderlichen Rechten und prüfen Sie die Antwort, anstatt Annahmen zu treffen.

Dieser Endpunkt erfordert keine Organisations-ID. Ihr Schlüssel identifiziert bereits die zugehörige Organisation, und die Antwort ist entsprechend eingeschränkt.

Ausprobieren

Ersetzen Sie alles in spitzen Klammern durch Ihre eigenen Werte und den Platzhalter für den Schlüssel durch einen Schlüssel aus Ihrem Dashboard.

curl -X POST https://api.zinndigital.com/v1/marketplace/vendor/payout-methods \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "rail": <string> }'

Angemeldet? Die API-Konsole in Ihrem Dashboard trägt automatisch Ihre echte Organisations-ID sowie Ihren eigenen Schlüssel ein und führt die Anfrage gegen die Live-API aus, sodass Sie die tatsächliche Antwort sehen können. Öffnen Sie diesen Endpunkt in der API-Konsole

Details

docs/82 §7c. The row is created **unverified** and can receive nothing: only staff verification makes it payable, and then only after the 48-hour cooling-off. ⛔⛔ **A change of destination is a new row, never an edit** — there is deliberately no endpoint that changes `destination` on an existing one. §7c: *"Change of payout details is the account-takeover cash-out route, and must be treated as one."* Editing a verified row would keep its verified state and its long-expired hold while pointing the money somewhere nobody looked at. ⭐ Re-adding a destination the seller already has returns the existing row rather than minting a second one — otherwise "change it and change it back" resets the cooling-off clock in two requests. ⛔ The **network** is its own field, not part of the address. Sending USDT TRC20 to a BEP20 address loses the money irrecoverably, so the same address on two networks is two destinations, each earning its own proof and its own hold.

Anfragekörper

NameTypErforderlichWas es ist
railstringJa
destinationstringNeinEmpty for account credit, which has nowhere to send.
networkstringNein
labelstringNein

Antwort

NameTypErforderlichWas es ist
idstringJa
railstringJa
rail_namestringJa
destinationstringJa⛔ **Masked, always.** Enough to recognise which account this is, never enough to reproduce it. The whole value never leaves the engine on a read path.
networkstringJa⛔ Its own field, never folded into the address. Sending USDT TRC20 to a BEP20 address loses the money irrecoverably (docs/82 §7b), so the network is part of the destination's id…
labelstringJa
stateMarketplacePayoutMethodStateJaWhere one destination is in its own verification (docs/82 §7c). `retired` rows are kept rather than deleted — a payout that went there is explained by them.
proof_kindMarketplacePayoutProofKindJaHow ownership of the destination was shown. ⛔ Crypto is the honest exception and is recorded as one: docs/82 §7c states that *no document can prove wallet ownership*, so a signe…
rejection_reasonstringNein
is_defaultbooleanJa
verified_atstringNein
hold_untilstringNeindocs/82 §7c's 48-hour cooling-off on the **first** payout to this destination — long enough for the change notice to land, short enough that a seller who genuinely changed bank…
permitted_proof_kindsMarketplacePayoutProofKind[]Ja

Fehler, die dieser Endpunkt zurückgeben kann

401 · 404 · 422