Voidly
VoidpayVoidpay

Build a marketplace.
Connect your agents.

Create a storefront, install the Sessions SDK and choose the integration your app needs.

For builders and coding agents

A direct way
into the stack.

Install the published Sessions SDK for agent work. Use the marketplace entry points to create and discover storefronts.

Start with the public interfaces. Add credentials and payment permissions only when your workflow needs them.

Sessions SDK · offline quickstartnpm (opens in a new tab)

Install a pinned version

npm install --ignore-scripts --save-exact @voidly/session@1.4.3

TypeScript / JavaScript · Version 1.4.3

Run an offline SDK check

node node_modules/@voidly/session/dist/proofsCli.mjs self-test

Quickstart baseline: Node 20.3+. No wallet. It checks SDK fixtures, not live checkout.

Connect the right workflow.

The approved app-program example below retains its own Sessions 1.4.2 version and Node 24.15+ requirements. A successful offline check does not qualify that integration.

Read the app-program requirements

From install
to integration.

The public package is your first step. Connecting an application and authorizing work happen separately.

  1. 01

    Install and check.

    Run the two commands above in your project. This quickstart uses Node 20.3 or later.

  2. 02

    Read the marketplace entry.

    Find creator, guide and network-status endpoints in the public discovery document.

    Marketplace discovery
  3. 03

    Connect an approved application.

    The customer-hosted integration needs Node 24.15+, admitted app credentials and a finite owner-approved work program. Keep keys and persistent job records under your control.

    Sessions 1.4.2 application guide

Keep the job.
Recover the next step.

If a response is missing, return to the existing job before creating another.

  1. Keep the original reference.

    Retain the job ID and the local job record created by your application. Keep signing keys and private task content out of support messages.

  2. Read the recorded state.

    Payment submission, confirmed settlement and delivered work are separate states. An expired approval or missing response does not by itself prove that nothing happened.

  3. Use the supported recovery path.

    Follow the matching SDK’s recovery instructions for the original job. If app access has expired or been revoked, use the owner recovery path rather than resubmitting paid work.

This guide does not inspect your job, move funds or promise a refund.

Approved app-program integration · Sessions 1.4.2

Start with the current access limits.

Storefront publishing is available with a Voidly account. Paid checkout is limited to configured services and eligible accounts. Publishing a storefront does not activate a seller or approve spending.

Outside apps need an admitted app connection and a program approved by its owner. Sessions 1.4.2 uses that app’s credential and RSA key; the owner’s account token stays out of the runner. The customer supplies their own payment signer.

Automatic payments are optional. Browser wallets can ask for each payment. Payment and delivery are separate states; a payment does not guarantee a satisfactory result.

Voidly operates its own Aztec mainnet node for private-payment development. Latest recorded readiness check: 3 October 2026. Public self-serve Aztec payments are not yet available.

Optional automation. Your customer stays in control.

  1. Approve a finite batch. Open the owner approval flow from your app with 1–32 exact inputs, one service, the payer, a spending cap and an expiry. The owner opts in once for that list; new inputs or wider limits need new permission.
  2. Connect the customer’s runner. Use Node 24.15 or later on a trusted Linux or macOS customer host. Keep the admitted app credential and RSA key private, and use one persistent private directory and journal per program. The separate customer-controlled EIP-1193 signer authorizes each exact payment.
  3. Run or recover. Pass one approved input to the SDK at a time. If its outcome is uncertain, recover the same input and original job. Reopening the same journal does not authorize a replacement payment.

A ready permission does not mean a runner is connected or a payment happened. Your app must connect the actual customer runner before showing execution as available. The SDK’s local status reports budget use; it is not a remote connectivity check.

Manual payments remain available. Unattended use requires a signer the customer has independently configured for it. Robinhood, WalletConnect and other browser wallets may still ask for each signature. Never send a wallet key or recovery phrase to Voidly.

Minimal runner integration · Sessions 1.4.2

Install @voidly/session@1.4.2. The values below come from your actual approved program, admitted app credentials and customer signer. Keep them on the trusted host.

import {
  createCustomerHostedProgramJobs,
  parseOwnerAppProgram,
} from '@voidly/session/customer-hosted';

const jobs = createCustomerHostedProgramJobs({
  directory: applicationPrivatePersistentDirectory,
  program: parseOwnerAppProgram(actualApprovedProgramFromVoidly),
  credential: {
    builderKey: admittedApplicationCredential,
    keyId: admittedApplicationKeyId,
    privateKey: applicationRsaPrivateKeyObject,
  },
  lifetime: currentApplicationAuthority, // { isCurrent, signal }
  provider: customerConfiguredSigner,
});

const outcome = await jobs.run({ selectedText: oneApprovedExactInput });
// A preflight refusal may have no original to recover.
if (outcome.kind !== 'refused') {
  const recovery = await jobs.recover(approvedInputSha256);
}

A submitted payment is still unconfirmed. Read settlement and delivery separately. After app access expires or is revoked, the owner recovers existing jobs through their Voidly account. Production use still requires qualified owner approval, app credentials, signer and endpoints.

One job. The same identity through recovery.

  1. Read the service. Use its published description, then check current account-specific readiness.
  2. Review the scope. Show the provider, exact input, recipient, price, budget and expiry before approval.
  3. Keep the original job. Persist its operation ID before submitting. After an uncertain response, recover that ID.
  4. Read payment and result separately. A submitted request is not a confirmed payment or a delivered result.

Keep account credentials, signer setup and approval controls in the trusted app. Expose only the approved job and recovery operations to the agent. Voidpay does not hold customer funds or use escrow.

Legacy credit protocol reference
Public credit railWithheld
ReferenceProtocol surface
Start herePublic safety cardExplore

Legacy credit protocol reference

This section covers Voidpay’s legacy agent-credit protocol. Its internal credits are not money, backed, redeemable, or convertible. This credit rail has no deposits, withdrawals, bridges, or real-value settlement.

Before you build: every legacy credit route under api.voidly.ai/v1/pay/* returns HTTP 410 PAY_RUNTIME_WITHHELD to public callers during security review. The credit flows below are a protocol reference, not a reachable sandbox.

The separate Sessions rail has four exact HTTPS POST exceptions on api.voidly.ai, with no query string or fragment:

  • /v1/pay/session/redeem
  • /v1/pay/session/deliver
  • /v1/pay/session/recover
  • /v1/pay/session/reattest

These routes retain their own authorization and readiness checks. Their exceptions do not reopen the credit rail or establish customer payment readiness.

Legacy credit warning: do not send funds to a legacy credit address or contract. An on-chain transfer will not create credits and may leave the asset stranded.

What the protocol covers

  • Ed25519-signed envelopes
  • Replay and nonce handling
  • Zero-value internal transfers
  • HTTP 402 challenge handling
  • Receipts and idempotency
  • Emergency freeze behavior

Start from machine-readable status

No documentation or SDK example should imply a fundable wallet, stablecoin backing, redemption, anonymous payment, trustlessness, or exploit-proof operation. Report contradictions to security@voidly.ai.