Phygitals Public API
The Phygitals Public API gives account holders programmatic access with user-scoped API keys:
browse packs and marketplace filter facets, buy packs with crypto, and sell claw items back to the
pool. All requests target https://api.phygitals.com.
Documented request and response shapes match what the API serves.
Authentication
API keys are user-scoped: create one in the Phygitals web app under Settings → API keys
(enable API access first; a connected Solana wallet is required). Keys start with phy_ and are
shown in full exactly once at creation. A lost key cannot be recovered, so revoke it and create a
new one. Treat keys like passwords: keep them in an environment variable or secrets manager,
never hardcoded or shipped client-side.
Authenticated endpoints accept the key in either header:
X-API-Key: phy_your_secret_keyAuthorization: Bearer phy_your_secret_key
Keys carry scopes: vm.buy.crypto (pack purchase endpoints), marketplace.take-claw-bid
(claw buyback endpoints) and vault.claim (physical claim endpoints); new keys receive all three by default. A
request with a missing, invalid, or revoked key returns 401, as does one whose key lacks the
endpoint's scope. Authenticated endpoints are rate-limited; exceeding a limit returns 429.
The catalog reads in this reference (the pack listing, the chase-card previews, and the
marketplace filter facets) require no credential. The pack-buy settle and its status poll
require a key holding the vm.buy.crypto scope; the buyback quote and the two claw-buyback
endpoints require a key holding marketplace.take-claw-bid. On buyback init, pass
owner_wallet when opening a sellback for a holder who will co-sign.
The six Vault endpoints require a key holding vault.claim. They claim a holder's vaulted
cards for physical delivery and follow the order afterwards. Every call takes owner_wallet;
claim-init also takes a wallet_proof from that holder. The Vault
section below has the lifecycle, the proof format, and the statuses.
Errors
An error response carries a conventional HTTP status and a JSON envelope:
code (a stable machine-readable string, e.g. INPUT_VALIDATION_FAILED), status,
message, defined (whether the code is one the endpoint documents), and an
optional data object with structured detail (for INPUT_VALIDATION_FAILED, the
{ formErrors, fieldErrors } from the failed request). For backward compatibility the body
also includes an error field equal to message.
Each endpoint documents only the codes it can actually raise, grouped by HTTP status, rather than
a catalog-wide list. A status that answers with one code names it in a code const and carries
that code's meaning as the body description; a status that answers with several publishes a code
enum and a per-code meaning table. Either way every code carries a copy-pasteable example showing
the message that endpoint returns.