putty
API ReferenceArtifacts

Mint one edition

Mints one edition of a drop. Which of two things happens depends on the drop's price, and the response tells you which: **A free drop (`priceUsd` "0.00") is minted immediately.** The response is a `FreeMintResponse`: the edition that was claimed, the drop's supply after the claim, and the drop itself. The edition number is assigned by the server and is unique within the drop. **A paid drop opens a checkout and is NOT yet minted.** The response is a `MintCheckoutResponse` carrying `checkoutUrl`, the amount, and the `payTo` address the payment settles to. The edition is claimed when the payment provider reports the payment settled, so a collector who abandons the page has not taken an edition off the shelf. `payTo` is **the creator's own address** — putty never holds a creator's takings, and there is no deployment address this route can fall back to. A mint against a drop with nothing left is a 409 with code `sold_out`. The supply check and the claim are one atomic operation, so two collectors racing for the last edition cannot both get it: one is served and one is refused.

POST
/creator/drops/{dropId}/mint

Mints one edition of a drop. Which of two things happens depends on the drop's price, and the response tells you which: A free drop (priceUsd "0.00") is minted immediately. The response is a FreeMintResponse: the edition that was claimed, the drop's supply after the claim, and the drop itself. The edition number is assigned by the server and is unique within the drop. A paid drop opens a checkout and is NOT yet minted. The response is a MintCheckoutResponse carrying checkoutUrl, the amount, and the payTo address the payment settles to. The edition is claimed when the payment provider reports the payment settled, so a collector who abandons the page has not taken an edition off the shelf. payTo is the creator's own address — putty never holds a creator's takings, and there is no deployment address this route can fall back to. A mint against a drop with nothing left is a 409 with code sold_out. The supply check and the claim are one atomic operation, so two collectors racing for the last edition cannot both get it: one is served and one is refused.

Authorization

bearerAuth
AuthorizationBearer <token>

A bearer token. The Account routes accept a Privy access token; the MCP transport accepts an sk- API key issued by POST /account/api-keys.

In: header

Path Parameters

dropId*string

The drop's id. The last segment of its public mint-page URL.

Length1 <= length <= 64

Request Body

application/json

Who is minting, and how they are paying. method is required for a paid drop and ignored for a free one.

TypeScript Definitions

Use the request body type in TypeScript.

Response Body

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

curl -X POST "https://example.com/creator/drops/string/mint" \  -H "Content-Type: application/json" \  -d '{}'
{  "checkoutUrl": "string",  "method": "card",  "currency": "string",  "totalUsd": "string",  "payTo": "string",  "expiresAt": "string",  "supply": {    "supply": 0,    "minted": 0,    "remaining": 0,    "soldOut": true  }}

Compose a drop's onchain deploy POST

Composes the transaction that publishes this drop onchain and hands it back UNSIGNED: the predicted contract `address`, the `calldata` for the creator to sign, the ABI-encoded `encodedArgs`, and the five `args` in constructor order so a page can show exactly what is being signed. **putty holds no key, signs nothing, and broadcasts nothing.** The drop is owned by the wallet in `args` and minted only by it, so a server that signed the deployment would own every drop it published. You sign `calldata` with your own wallet and send it to `factory` yourself. Calling this route changes no state and can be repeated as often as you like — it is a preview, not a publish. **The factory is this deployment's, never yours.** `factory` is read from configuration, so it cannot be supplied in the body: a request-chosen factory would let you be handed a prediction for a contract putty does not control, which would look entirely correct and would never deploy anywhere. A 400 that mentions `factory` is this api's own body validator refusing an unknown field — this route has no request body, so there is nothing to put one in. **When no factory is configured, `address` is the zero address and `calldata` is `0x`.** A drop deployed by your own contract lands wherever that contract's salt puts it, and putty does not invent an address for it. `args` and `encodedArgs` are still correct in that case: deploy the drop yourself with them. A drop belonging to another creator answers with the same 404 as one that does not exist, byte for byte, so this route cannot be used to find out whose drops exist. A drop putty will not compose — no name, no symbol, a supply below one, a royalty outside 0-10 000 — is a 400 whose `error.code` is the machine-readable reason: `name_required`, `symbol_required`, `supply_invalid`, `royalty_invalid`, or `creator_invalid`. A drop with no `creatorAddress` set at all is a 400 with the code `creator_address_required` — the one address an onchain drop cannot go without, which no amount of retrying will supply, so that page should send the creator to `PATCH /creator/drops/{dropId}` rather than to retry.

The caller's showcase entries GET

Every entry the authenticated creator owns, newest first, in **any** status — draft, published, and withdrawn alike. This is the only route that can see a draft, and it is scoped to the caller by an owner filter in the query. A creator's unpublished work is invisible to every other account, and the public listing has no owner dimension through which it could leak.