Gate checkout

​

Which API host?

​

Lifecycle

1. Snapshot: load the public gate with its requirements, price, schedule, and whether a reward exists. The secret reward value stays out of the snapshot. Use client.getGate(gateId) or GET /api/v1/profile/gates/{gateId} on api.proofable.me.
2. Eligibility: GET /api/v1/proofs/check?gateId=...&address=...&includePrivate=true&includeQHashes=true evaluates the visitor’s existing proofs against every requirement. An inline Gate Policy uses the same evaluator over POST /api/v1/proofs/check and collects no listing payment.
3. Verify: if proofs are missing, the visitor completes them (hosted verify link, VerifyGate, or POST /api/v1/verification for signature-based verifiers). Pass gateId and reuse satisfied proofs via options.reusedVerifierProofs.
4. Pay: for paid gates, payment happens after verification by default (executionOrder: "verifyThenCharge"). Gates with a connected payout account settle through one Stripe checkout session, where the visitor picks card or crypto. Gates with a custom wallet settle by direct USDC on Base.
5. Fulfill: deliver the reward with the verified qHash (plus payment evidence for paid gates) via client.fulfillGate(...) or POST /api/v1/gates/{gateId}/fulfill. If the snapshot includes requestedAccess, also send the buyer-approved accessGrant (connected account + selected resource). Hosted checkout stamps that grant on the receipt. A configured return URL receives grant and receipt set to the same proof ID. The listing owner then calls POST /api/v1/proofs/composio/execute with grant set to that proof ID. Proofable runs the tool as the buyer and never returns the buyer’s credential. Missing, revoked, or out-of-scope grants return 403. For an AI service listing, also send the buyer’s serviceParameters (see AI service listings).

import { ProofableClient } from '@proofable/sdk';

const client = new ProofableClient();

// 1. Snapshot
const gate = await client.getGate('gate_your-listing');

// 2. Eligibility
const check = await client.gateCheck({
  gateId: 'gate_your-listing',
  address: visitorWallet,
  includePrivate: true,
  includeQHashes: true,
});

// 5. Fulfill (after verify + pay)
const reward = await client.fulfillGate({
  gateId: 'gate_your-listing',
  qHash: verifiedQHash,
  walletAddress: visitorWallet,
});

​

Reading the gate check

{
  "success": true,
  "data": {
    "eligible": true,
    "gate": {
      "gateId": "gate_your-listing",
      "allRequiredSatisfied": true,
      "satisfiedVerifierIds": ["proof-of-human", "wallet-risk"],
      "missingVerifierIds": [],
      "reusedVerifierProofs": {
        "proof-of-human": "0xabc…",
        "wallet-risk": "0xdef…"
      }
    }
  }
}

• satisfiedVerifierIds / missingVerifierIds: which requirements existing proofs cover.
• prerequisites: present when the listing requires prior listings. One { gateId, satisfied } row each. See Prior listings.
• reusedVerifierProofs: verifierId → qHash map (requires includeQHashes=true). Pass it as options.reusedVerifierProofs on POST /api/v1/verification so satisfied checks are not re-run.
• Re-run the gate check after every interactive step (OAuth grant, personhood session). An interactive step counts once this check confirms it.

​

Request-time vs proof-based rules

​

Verification links

​

Paid gates

• amountUsd, label, methods (usdc, stripe), cardPayoutReady
• executionOrder: verifyThenCharge (default): verification completes first, then payment, then fulfill.

• stripe: hosted Stripe Checkout (card). Available when the gate has a connected payout account.
• usdc: direct on-chain USDC transfer on Base. The only method for custom-wallet payout gates.

• Stripe: paymentCheckoutSessionId from the checkout return.
• USDC: paymentTxHash of the on-chain transfer.

​

Fulfillment result

{
  "success": true,
  "data": {
    "gateId": "gate_your-listing",
    "qHash": "0xabc…",
    "fulfillment": {
      "delivery": "redirect",
      "type": "redirect_url",
      "value": "https://app.example.com/members"
    }
  }
}

​

AI service listings

const order = await client.fulfillGate({
  gateId: 'gate_your-service',
  qHash: verifiedQHash,
  walletAddress: visitorWallet,
  serviceParameters: [{ name: 'url', value: 'example.com' }],
});

order.data.fulfillment.delivery; // 'access_granted'
order.data.serviceJob.jobId; // the run this order started

{
  "meta": {
    "marketplace": {
      "serviceJob": {
        "jobId": "…",
        "status": "completed",
        "result": "The answer, up to 8,000 characters"
      }
    }
  }
}

​

Campaign windows

​

Prior listings

• Gate checks fold prerequisites into allRequiredSatisfied and list them in gate.prerequisites.
• Verification and fulfillment refuse a visitor who is missing one with GATE_PREREQUISITE_MISSING and details.missingGateIds, before any check runs or credit is spent.
• Publishing refuses a prerequisite that was never published (GATE_PREREQUISITE_NOT_FOUND) or that requires this listing back (GATE_PREREQUISITE_CYCLE). A paused or ended prerequisite stays valid, since past visitors still hold its receipt.

​

Next