Integrating Alt's auction floor and Alt Value pricing

Every other Thursday, Alt's Liquid Auction closes. Per the Alt help center the auction runs for ten days, and a single integration project lives inside that cycle: it has to read the lot state, the bid, the Alt Value, the consignment ledger and the vault inventory all on the same clock. That is where most of the work for this app actually sits.

Alt Platform Inc. operates the alt.xyz marketplace from San Francisco and pairs the consumer flow with collateralised lending. Cards in the Alt Vault back loans; the cash-advance program funds, per Alt's marketing material, 72% of accepted lot value the day a consignment is taken on. Trinity Capital's July 18, 2025 release describes a $40M asset-based credit facility behind the lend leg and puts the platform in roughly 76 countries — those are the two outer perimeters an integration has to be honest about. Everything that follows assumes an authorized engagement with the account owner whose data the integration will read.

Where the app keeps the data

Six surfaces matter for an integration, and they do not all use the same identifiers. The auctions and the vault are joined on the Alt asset id; Alt Value is joined on a card identity that survives across grading services. The user-side state — watchlist, saved searches, advance balance — is keyed on the account.

Routes into alt.xyz we'd actually take

Three are practical here. Each is described as work we routinely run; access arrangements happen during scoping, with you.

Authorized interface integration of the alt.xyz mobile app

The Android binary (version observed in the Play Store at time of write) is the cleanest source of the production traffic shape. With the account owner's authorization, we capture the live calls behind auctions, lot detail, Alt Value, vault inventory and the advance ledger, identify the auth chain (token plus device header on the Bearer leg, a session cookie on the web surface), and rebuild the relevant endpoints as a documented API. Reach: nearly everything the user sees, including the bid socket as a lot closes. Cycle: one to two weeks. Durability: medium — the app ships on a normal mobile cadence, and the test suite is what catches drift between releases.

User-consented session through the web flow

Where a customer prefers not to ship around the mobile capture, we drive the alt.xyz web session through the consenting user's login and pull the same domains as the mobile shape. Reach: most of the read surfaces; some auction events arrive a beat later than the mobile socket. Cycle: similar. Durability: a touch better, because the web surface changes more slowly. Studio role: write and operate the auth bootstrap and the consent record so the user can revoke at any time.

Native export, where it exists

Alt's seller dashboard exposes sales and payout reports a consignor can pull on their own. For a portfolio or accounting integration that only needs settled history rather than live state, that path is the lightest. Reach: settled sales, payouts, advances. Cycle: under a week. Durability: high. We use this as the fallback or the warm-start for a richer build, not as the only feed when the customer needs the live auction state.

On a typical Alt scope the mobile-side capture carries most of the build — it covers the live auction state, the vault and the advance ledger in one place, while the other two slot in where the use case actually needs them.

Code, spec and tests we hand over

The deliverable is runnable, not advisory. Concretely, for an Alt build:

• An OpenAPI 3.1 spec for the auctions, valuation, vault and advance-ledger endpoints, with each schema matched back to a real surface in the app rather than a wishlist.
• Python and Node clients with auth handlers — Bearer token plus device header, with refresh — and the bid-socket subscription wired so a downstream service can pin to a lot.
• A protocol and auth-flow report covering the token rotation, the alt.xyz session cookie chain, and the live bidding socket including the extended-bidding state machine.
• Pytest fixtures against a logged-in test account so the suite catches a backend change before it reaches production.
• Interface documentation, written for an engineer who has to keep this running after we leave: endpoint catalogue, identifier joins, retry policy, and the failure shapes Alt actually returns.
• A short data-retention and consent note that names what is logged, where, for how long, and how the user revokes.

A short slice of session code

An illustrative client for a logged-in Alt session. Endpoints and headers are confirmed during the build against a consenting test account; the snippet below shows the shape, not the literal route table.

# alt_client.py — illustrative, confirmed during the build
import httpx
from datetime import datetime

class AltClient:
    BASE = "https://api.alt.xyz"

    def __init__(self, session_token: str, device_id: str):
        self.s = httpx.Client(headers={
            "Authorization": f"Bearer {session_token}",
            "X-Alt-Device": device_id,
            "Accept":        "application/json",
        }, timeout=15.0)

    def liquid_auction_lots(self, cursor: str | None = None) -> dict:
        params = {"limit": 50}
        if cursor: params["cursor"] = cursor
        r = self.s.get(f"{self.BASE}/v1/auctions/liquid/lots", params=params)
        r.raise_for_status()
        return r.json()  # {"lots":[...], "next_cursor": "..."}

    def alt_value(self, card_uid: str) -> dict:
        r = self.s.get(f"{self.BASE}/v1/values/{card_uid}")
        r.raise_for_status()
        return r.json()  # {"value": 1240.00, "as_of": ISO8601, "basis": "comps"}

    def vault_inventory(self) -> list[dict]:
        r = self.s.get(f"{self.BASE}/v1/me/vault/items")
        r.raise_for_status()
        return r.json()["items"]

    def advance_ledger(self, since: datetime) -> list[dict]:
        r = self.s.get(f"{self.BASE}/v1/me/advances",
                       params={"since": since.isoformat()})
        if r.status_code == 401:
            raise PermissionError("session expired; refresh and retry")
        r.raise_for_status()
        return r.json()["entries"]

Things we account for in the build

A few notes specific to this app that shape how the project actually runs.

• The auction clock is not a polling target. Liquid Auction lots use extended bidding — the close stretches when bids land late. We design the auction subscriber around the socket, not a fixed-interval poll, and the integration carries the extended-bid state machine end to end so a downstream alert does not fire on a lot that has not really closed yet.
• Vaulted versus raw is one branch, not two products. Per the help center, vault eligibility is restricted to PSA, BGS, BVG, SGC and CGC graded slabs above a value threshold. Raw and unsupported slabs do not enter the lend path. We carry both through the same asset schema with a single eligibility field, so downstream code branches once rather than maintaining two parallel pipelines.
• Alt Value is not a static number. The pricing engine recomputes as comparable sales land from eBay, MySlabs and the auction houses Alt tracks. We tag every value read with an as-of timestamp and set a short cache window during the build so a treasury or risk consumer sees the freshness it needs without melting the rate limit.
• The platform changes. Alt has been shipping product over the last two years (new seller dashboard, lending program scale-out behind the Trinity Capital facility). We bake a small change-detection suite into the test fixtures so a backend rename surfaces during the next CI run rather than in production.

Consent and the regulatory perimeter

Two perimeters apply. On the marketplace side, Alt sits within the US state-by-state consumer-protection and KYC framework expected of any platform that takes custody of consigned assets and routes payouts to sellers; the onboarding flow at alt.xyz collects the identity material that satisfies it. On the lending side, the cash-advance and collateralised-loan products — funded in part by the credit facility announced July 18, 2025 — bring state lender licensing into scope per jurisdiction.

For the integration itself the practical effect is the same on either side. The dependable basis for reading a user's Alt account is that user's own written authorization, logged with timestamp and scope. Data minimization stays tight: we read only what the integration needs and we do not pull the full account export when the use case wants the advance ledger. Across the 76 countries the marketplace covers, GDPR data-minimization and a data-processing record apply for EU residents; CCPA/CPRA consumer rights apply for Californians. NDAs are signed where needed, and we keep nothing past the project's retention window.

How the engagement runs

Source-code delivery for an Alt build starts at $300 and is paid only after you have run the artefacts and confirmed they work against your account. The hosted variant skips the upfront fee entirely — you call our endpoints and pay only for the calls you make. A typical project runs one to two weeks from scope to handover: the OpenAPI spec, runnable Python and Node clients, the pytest suite against a real session, the protocol and auth-flow report, and the interface documentation a downstream team needs to keep the pipeline running. Scoping, access arrangements with you, and the compliance posture are part of that cycle — not a homework list ahead of it. Send the app name and what you want from its data through the contact page and we take it from there.

What was checked, and what's cited

This brief leans on Alt's own help-center articles for the auction, vault and lending mechanics, and on the Trinity Capital release for the funding and country-coverage figures. The integration angle and the engagement terms are the studio's. Sources opened during the write-up:

• Selling in Alt Auctions (Alt Help Center)
• The Alt Vault (Alt Help Center)
• Alt Lending (Alt Help Center)
• Trinity Capital — $40M facility for Alt Platform Inc., July 18, 2025

OpenBanking Studio integration desk — assessment dated 2026-05-30.

Questions integrators usually ask

Does an Alt integration cover both the Fixed Price Marketplace and the Liquid Auction?

Yes — they are different surfaces in the app and we map both. Fixed Price reads as a normal catalogue with seller, asking price and listing age. Liquid Auction adds lot status, current high bid, the extended-bidding flag and the close window for the every-other-Thursday cycle. We expose them as two endpoints in the spec so a downstream caller can subscribe to auction state without re-reading the whole catalogue.

How fresh is the Alt Value number when we pull it through the integration?

Alt describes Alt Value as a real-time pricing engine that recomputes as new comparable sales land from eBay, MySlabs and the auction houses Alt tracks (per the Alt help center). In practice we cache the read for short windows — seconds to a minute — because a busy card can repaginate quickly. The TTL is a config knob we set during the build.

Can we sync a user's saved searches and watchlist out of the app?

Against a consenting account, yes. Saved searches and watchlists are per-user state Alt persists server-side; the integration exposes them as a read endpoint and, when scope includes write, a mutation endpoint so a downstream tool can keep them in sync.

What changes once a card moves into the Vault versus a raw listing?

Vaulted cards carry an Alt-issued asset record — digitized images, grading attribution (PSA, BGS, BVG, SGC or CGC per the help center), an insurance flag, and eligibility for the collateralized loan program. Raw or unsupported cards do not have the lend path and are flagged as such in the schema. The integration surfaces both, with a single eligibility field that downstream code can branch on.

Adjacent marketplaces in the same data picture

A few real neighbours an Alt integration is likely to touch, directly or by overlap. None of the below are clients or partners of OpenBanking Studio; they are listed because anyone integrating Alt usually has to think about them.

• eBay — the default cross-list target for Alt sellers; an integration often has to reconcile an Alt lot to a parallel eBay listing.
• COMC (Check Out My Cards) — long-running consignment marketplace; useful where a portfolio tool needs comparable cross-consignor history.
• PSA Card (the former StockX sports-cards marketplace) — graded-only catalogue tied to PSA's grading and pop reports; shares the slabs-first shape with Alt.
• TCGPlayer — dominant marketplace for Pokemon, Magic and other trading-card games; same buyer base, different category.
• Whatnot — live-stream auctions for sports and TCG cards; complements Alt's scheduled cadence with a continuous one.
• Goldin — premium auction house for six-figure-plus lots; the consignment ledger shape rhymes with Alt's higher tier.
• MySlabs — peer-to-peer marketplace for graded slabs; one of the comparable-sales sources Alt Value reads from.
• PWCC Marketplace — vaulted-only marketplace and auction; closest analogue to Alt's vault-as-catalogue model.
• Sportslots — long-running marketplace with deep vintage baseball stock.
• Slabstox — data-forward marketplace with per-card history pages, in the same value-data niche as Alt.