How do I mock the Pinata API locally?

Install stunt, add a one-service block to stunt.yaml (adapter: embedded:pinata-style), and run stunt up. You get a local, stateful stand-in for Pinata API 1.0 — 6 routes over rest — with no remote account, no network, and no bills.

Is the Pinata API mock data synthetic?

Yes — entirely. The adapter returns generated data only; stunt's adapter lint rejects real-looking secrets and PII at build time. It simulates the shape and behavior of Pinata API (routes, status codes, pagination, webhooks), never real records.

← all adapters

pinata-style

simulates Pinata API 1.0

restadapter v0.1.06 routes

verification

VMVM tier — no SDK suite yet· surface 6 · not implemented 4 · differs 3

use it

# add to stunt.yaml
services:
  pinata:
    adapter: embedded:pinata-style

# then
$ stunt up

The embedded: source extracts this adapter from the binary — no git clone, fully offline.

how to mock the Pinata API locally

Install stunt, paste the service block above into stunt.yaml, run stunt up — then point your client at localhost instead of Pinata API. It works offline, keeps state across requests and restarts, and every response is synthetic: the route shapes, status codes, pagination, and webhook delivery follow the real Pinata API 1.0 surface — the data is fake, the behavior is real.

backing stores

pins

api surface (6)

generated from the adapter manifest — exactly what boots, nothing more

6 routes

POST/pinning/pinFileToIPFS

POST/pinning/pinJSONToIPFS

DELETE/pinning/unpin/{cid}

GET/data/pinList

GET/data/testAuthentication

GET/data/pinByHash

VM-verified behaviors (10)

✓missing or half-present credentials are 401 with the error envelope
✓the API key pair and a Bearer JWT both open testAuthentication
✓pinJSONToIPFS pins content to a real CIDv0
✓re-pinning identical content is isDuplicate, not a new pin
✓pinFileToIPFS sizes and names the pin from the multipart parts
✓pinList filters by hash, size, status, and metadata name
✓pinStart/pinEnd bound the date-pinned window
✓pinByHash requires hash and matches the CID exactly
✓pinList pages at the real default of 10 rows
✓unpin removes the CID; a second unpin is 403 FORBIDDEN

Not implemented (4)

No pin-by-CID endpoint (POST /pinning/addHashToPinQueue)
No pin-jobs listing (GET /pinning/pinJobs)
No metadata update or pin-policy change (POST /pinning/hashMetadata)
No pinned-data-usage endpoint (GET /data/userPinnedDataTotal)

Differs from the real API (3)

Credentials are presence-checked only; any non-empty key pair or Bearer JWT passes
Every stored pin is status pinned — unpinned/pending/failed not modeled (no job queue)
JSON pin CIDs derive from stunt canonical serialization, not byte-identical to real Pinata

full scorecard →

want more of the Pinata API surface? adapters are YAML + Starlark — the authoring guide covers adding routes, fixtures, and state machines. Open an issue for anything big first, or just file a PR — merged routes ship in the next release.