APIX

APIX turns APIs into paid digital products in minutes, not months.

Deployment

• Avalanche Testnet (AvaCloud): explorer-test.avax.network/apix
• Demo deployment : unloc.kr

TL;DR

• APIX is an HTTP-native monetization layer for APIs, built for AI agents, API providers, and Web3 infrastructure teams.
• Pay-per-call access is enforced with an x402-style flow and on-chain verification.
• Quota and entitlement products are the next step, so providers can evolve from single-call pricing to package-based monetization.
• Provider control stays intact: APIX sits in front of provider-owned endpoints instead of requiring a marketplace-first model.

What APIX is

APIX is a focused product for teams that want to:

• add paid access to an API without rebuilding billing from scratch,
• support machine-to-machine and AI-agent payment flows,
• verify payment before serving a protected resource,
• and evolve from simple pay-per-call flows toward quota and entitlement models.

APIX should be understood first as:

1. API monetization middleware
2. payment verification and access-control layer
3. foundation for a future monetization control plane

What APIX is not

At the current stage, APIX is not a general API marketplace.

The product direction is centered on:

• provider-owned API endpoints,
• request-path payment enforcement,
• settlement-aware access control,
• and future operational controls such as replay prevention, reconciliation, and admin workflows.

Why teams choose APIX

• Monetize immediately: Add payment gating to an API endpoint with minimal middleware changes.
• Built for software buyers: APIX is designed for AI agents and machine-to-machine integrations, not only human checkout flows.
• Fair payment logic: 200 OK commits usage; failed responses roll back quota (No Data, No Pay).
• Clear upgrade path: Start with pay-per-call, then move toward quota and entitlement products.
• Provider-first control: Keep policy, settlement, and endpoint ownership on the provider side.

Commercial direction

The launch-stage commercial model is expected to follow this path:

• Free sandbox for learning, demos, and testnet experimentation
• Usage-based production for paid request flows and monetized endpoints
• Enterprise packaging for operational controls, support, and higher-trust deployments

This keeps the first integration lightweight while leaving room for larger operational deployments later.

How it works (simple view)

1. Client hits a protected endpoint.
2. APIX returns 402 Payment Required.
3. Client submits payment on Avalanche network.
4. Client retries with a payment proof (tx hash).
5. SDK verifies on-chain, issues a short session token, and the request is served.

This gives you the speed of API-first design with verifiable crypto settlement.

Telegram Agent Payment Demo

What is inside APIX

• apix-sdk-node/
  Runtime SDK for verification, quota/session checks, and standardized payment challenge responses.
• demo/backend/
  API-side reference implementation (/health, /metrics, protected routes).
• demo/frontend/
  React + Vite demo showing the payment challenge and retry flow end-to-end.
• execution/
  Scripts to run/build the demo quickly.

Run locally in minutes

Option 1: All-in-one

python execution/run_demo.py --verification-rpc-file /path/to/secure-verification-rpc.txt
# or for env-based setups:
# APIX_VERIFICATION_RPC_URL=https://your-rpc-endpoint python execution/run_demo.py
#
# Demo backend can also get the provider token for API-key style tenancy controls:
# APIX_PROVIDER_TOKEN=company-a-token python execution/run_demo.py

Starts backend (http://localhost:3000) and frontend, with readiness checks.

For remote hosts (bind frontend publicly), add:

python execution/run_demo.py \
  --backend-host 0.0.0.0 \
  --frontend-host 0.0.0.0 \
  --api-base-url http://PUBLIC_IP:3000 \
  --verification-rpc-file /path/to/secure-verification-rpc.txt

If browser and API are on different hosts (or behind a domain), set --api-base-url explicitly and configure APIX_ALLOWED_ORIGINS to the frontend origin.

Fast local verify

cp demo/backend/.env.example demo/backend/.env
cp demo/frontend/.env.example demo/frontend/.env

# 1) Set verification RPC and provider token (backend-only)
sed -i '' -e 's#^APIX_VERIFICATION_RPC_URL=.*#APIX_VERIFICATION_RPC_URL=https://subnets.avax.network/apix/testnet/rpc#' demo/backend/.env
sed -i '' -e 's#^APIX_PROVIDER_TOKEN=.*#APIX_PROVIDER_TOKEN=provider-token-placeholder#' demo/backend/.env

# 2) Set public RPC (frontend)
sed -i '' -e 's#^VITE_AVALANCHE_RPC_URL=.*#VITE_AVALANCHE_RPC_URL=https://subnets.avax.network/apix/testnet/rpc#' demo/frontend/.env

python execution/run_demo.py

If your shell doesn't support sed -i '' (Linux/Git Bash), use normal sed -i.

Option 2: Step-by-step

cd apix-sdk-node
npm install
npm run build

cd ../demo/backend
cp .env.example .env
npm install
npm run start:compiled

cd ../demo/frontend
cp .env.example .env
npm install
npm run dev

Error handling and visibility

• Standard response fields include code, message, retryable, and request_id.
• X-Request-ID enables easy frontend ↔ backend traceability.
• Logs are structured with request_id, status, outcome, and latency_ms.

Current MVP limits

• On-chain verification is required (APIX_VERIFICATION_RPC_URL).
• Session persistence defaults to local file storage.
• /metrics is secured by Bearer token; production mode disables wildcard CORS.
• The demo emphasizes the payment challenge and retry flow, not a full production control plane yet.

Future roadmap

• Shared distributed session storage for multi-instance deployment.
• Expanded protocol compatibility (L402-style flow while maintaining current headers).
• Entitlement token and quota-pack support on top of the base pay-per-call path.
• Deeper observability: latency budgets, rollback ratio, and failure reason analytics.
• Operational control-plane features such as replay protection, reconciliation, and admin APIs.