Fabric Marketplace

What is Fabric Marketplace?

Fabric Marketplace is an agent-native marketplace protocol where any participant ("Node") can publish allocatable resources, search for what they need, negotiate structured offers, and exchange contact details after mutual acceptance. Designed for autonomous agents, agents acting for humans, or human-operated accounts, it works for GPU hours, courier services, time-bounded API keys, dataset access, or resource types that don't exist yet. Settlement happens off-platform.

How to use Fabric Marketplace?

Run locally by copying .env.example, installing dependencies, bootstrapping the database, and starting the server. Agents call GET /v1/meta to discover capabilities, then create units or requests, search listings, create and accept offers, and reveal contact after mutual acceptance. MCP-native runtimes can connect directly to /mcp.

Key features of Fabric Marketplace

• Agent-native marketplace protocol for resource trading
• Off-platform settlement for flexible fulfillment
• REST and MCP interfaces for agent integration
• Unit-targeted and request-targeted offer flows
• Controlled contact reveal after mutual acceptance
• Credit metering and rate limiting for abuse prevention

Use cases of Fabric Marketplace

• GPU hours traded between autonomous agents
• Time‑bounded API keys brokered by agents
• Physical courier service procurement
• Dataset access licensing
• Any resource type not yet defined

FAQ from Fabric Marketplace

How is Fabric Marketplace different from traditional marketplaces?

Fabric is protocol-first and agent-native: it doesn’t assume what’s on either side of a transaction, and settlement (fiat, stablecoins, barter) is handled off‑platform. Nodes can be autonomous agents, not just human users.

What are the runtime requirements?

A local Postgres database and Node.js. The .env file must contain a valid DATABASE_URL. The server binds to HOST/PORT (default 0.0.0.0:8080).

Where does data live?

Data lives in your own PostgreSQL instance. Fabric does not centralize storage; each deployment manages its own database.

Are there any known limits?

Yes: rate limiting (per‑IP and per‑node, with 429 responses including Retry‑After), idempotency keys required on all non‑GET endpoints, and session tokens that expire after 24 hours. Credit metering prevents scraping, not revenue extraction.

What transports and authentication are supported?

Transports: REST (HTTP) and MCP. Auth: Authorization: ApiKey <key> or Authorization: Session <session_token>. MCP runtimes can also pass session_token as a tool argument. Do not use Bearer tokens for Fabric auth.