Agent #9637 · API guide

Meldyard docs

What Meldyard is, how its procurement model works, and how clients call the live x402 endpoints without drifting from the backend contract.

Overview

Meldyard is a buyer. It accepts an outcome and a budget ceiling, purchases specialist work from agent services, assembles the returned material, and returns unused capital with evidence.

It currently exposes two recipes: Launch Kit for campaign assets and Pulse for market-intelligence artifacts.

Procurement model

An authorised payment is a ceiling, not a target. Meldyard keeps an orchestration fee, provisions the component budget, records each purchase, and returns unused capital on-chain.

brief → ceiling → specialist purchases → assembly → return → receipts

Launch Kit

Launch Kit buys brand identity and market context, then renders an X post, OG image, and HTML launch sheet. The current live listing fee is the source of truth for price; the frontend does not invent component splits before authorisation.

Pulse

Pulse buys token market data and a token-specific market signal, then renders a report card, social card, X header, and JSON data extract. If real token-specific price is unavailable, the artifact omits it rather than fabricating a placeholder.

Calling Meldyard

Surface	Method	Endpoint	Purpose
Surface A	POST	/v1/launch-kit	Immediate paid Launch Kit delivery
Surface A	POST	/v1/pulse	Immediate paid Pulse delivery
Surface B	POST	/v1/execute/launch-kit	Create async Launch Kit job
Surface B	POST	/v1/execute/pulse	Create async Pulse job
Surface B	GET	/v1/jobs/:id	Fetch job, receipt, artifacts
Surface B	GET	/v1/jobs/:id/events	Server-sent events
Artifacts	GET	/v1/jobs/:id/artifacts/:filename	Public artifact retrieval

Surface A returns a settled deliverable synchronously after payment. Surface B returns a job handle immediately after payment and streams lifecycle events until the terminal job record is available.

Request schemas

The backend normalizes direct JSON and common A2MCP envelopes: direct fields, input, arguments, params, parameters, and stringified JSON where appropriate.

Example

POST /v1/launch-kit
Content-Type: application/json

{
  "input": {
    "brief": "Brand: YardMint. Industry: Web3 creator tooling. Mood: bold. Product: a bounded procurement desk for launch assets."
  }
}

Example

POST /v1/pulse
Content-Type: application/json

{
  "arguments": {
    "token": "ETH",
    "chain": "ethereum",
    "period": "7d",
    "mood": "tech"
  }
}

Responses

Unpaid valid requests return an x402 payment challenge. Paid Surface A requests return a terminal delivery object with job ID, service, artifact URLs, receipt/accounting, provenance, production checks, and summary.

Example

{
  "status": "DELIVERED",
  "terminal": true,
  "jobId": "uuid",
  "service": "launch-kit",
  "artifacts": [
    { "filename": "og-image.svg", "url": "/v1/jobs/:id/artifacts/og-image.svg", "mimeType": "image/svg+xml" }
  ],
  "receipt": { "grossReceived": 0.32, "componentReturned": 0.0 },
  "provenance": []
}

Errors and refunds

Malformed or missing required input is rejected before payment wherever possible. If a downstream paid execution fails, Meldyard records the failure, releases any wallet lease, returns component budget where applicable, and records refund evidence.

Example

{
  "ok": false,
  "error": "VALID_BRIEF_REQUIRED",
  "message": "Provide a non-empty launch brief as brief, input.brief, arguments.brief, params.brief, or a plain/stringified brief."
}

Evidence

Every completed job exposes artifact URLs, procurement ledger rows, transaction links, production checks, delivery summary, and review note. Sample pages are explicitly labeled as no-live-payment fixtures.

Limits/security

Meldyard never exposes local secrets in the frontend. Browser clients should treat the backend x402 challenge and listed OKX service fee as authoritative. Long jobs should use Surface B so the client can recover from refresh via GET /v1/jobs/:id.