Artax

Use the left navigation to move between review, account, pricing, and setup pages.

ReviewAccountAdd-on

Developers

Choose an Artax integration path that fits your product.

Artax supports hosted review, direct API and SDK use, embedded review UI, and guided AI-agent onboarding. Start on devnet, validate the flow in your own product, and add a separate mainnet-beta key when you are ready for paid traffic.

Hosted reviewTyped APIEmbedded UIAI-agent path

Pick a starting point

The lightest setup starts with hosted review. From there you can move into typed SDK usage, reusable review components, and account surfaces that support scoped keys for agents, funded advisory access, and separate execution-request approval. Start on devnet, then create a separate mainnet-beta key when you are ready for paid traffic.

1. Hosted review link

Launch a trusted Artax review workspace with a prefilled intent and let the user keep signing inside their own wallet path.

2. Direct API and SDK usage

Call Artax through typed client helpers, React hooks, and launch utilities instead of rebuilding review and routing logic from scratch.

3. Embedded review UI

Reuse the Artax review module inside a partner app while keeping reviewed intent, warnings, and safety presentation consistent.

4. Human-assisted AI-agent path

Use the account APIs to create an account, refresh verification when needed, complete setup, then let the agent inspect account state, limits, funding status, and funding instructions through scoped keys before moving to a separate mainnet-beta key.

AI-agent setup

Give agents only the access they need

Agents can step through API-first onboarding, then operate inside a scoped key and project boundary instead of receiving unrestricted authority.

1

The agent discovers the current public builder and review surfaces, then creates an account through the guided account-lifecycle API.

2

If the account starts pending, the agent can refresh the verification step, complete it through the direct verification route or verification page, and receive the default project plus sandbox API key.

3

The onboarding responses make the current authority tier, allowed capabilities, funding requirement, and execution limits explicit instead of forcing the agent to guess.

4

The agent can then inspect account state, review current limits, read funding status, create narrower keys, issue a funded-advisory key once prepaid balance is available, and move into execution requests only through the separate approval path.

Access boundary

The onboarding wizard follows the same API-first flow: verification, browser continuation when needed, then scoped access with clear account boundaries.

Account operations

  • Create an account, request a fresh verification link when needed, complete verification, then inspect account, project, API key, balance, funding status, usage, funding instructions, and restrictions.
  • Create projects, create scoped API keys, revoke keys, and review project or API-key holds from the dashboard and API.
  • Use current advisory review access inside sandbox limits instead of jumping directly to funded or autonomous execution.
  • Retrieve prepaid USDC funding instructions without turning funding into an unsecured SOL flow.

Authority and approval boundary

Account read only

Available

Inspect account, project, balance, usage, authority, and restriction state.

Sandbox advisory only

Available

Use advisory review surfaces in sandbox and retrieve funding instructions.

Funded advisory only

Available

Prepaid USDC-backed funded advisory access is available once prepaid balance exists.

Human-approved execution request

Available

Execution-request keys use a separate manual-approval path. Higher-risk requests can be prepared in Artax, but they still require approval before they are sent.

Autonomous execution default

Disabled by default

Autonomous sponsored execution is not the baseline Artax mode.

Agent-ready HTTP

One direct review call

This is the smallest current integration path for coding agents and server apps: request bounded transfer sponsorship when needed, read the server decision, and only continue when the response allows it.

export async function reviewWithArtaxFetch() {
  const apiBaseUrl = process.env.ARTAX_API_BASE_URL;
  if (!apiBaseUrl) {
    throw new Error("ARTAX_API_BASE_URL is required.");
  }

  const headers = {
    "content-type": "application/json",
    ...(process.env.ARTAX_APP_KEY ? { "x-artax-app-key": process.env.ARTAX_APP_KEY } : {}),
    ...(process.env.ARTAX_ACCOUNT_API_KEY
      ? { "x-artax-api-key": process.env.ARTAX_ACCOUNT_API_KEY }
      : {})
  };

  const response = await fetch(`${apiBaseUrl}/api/analyze-transfer`, {
    method: "POST",
    headers,
    body: JSON.stringify({
      appId: "your-artax-app",
      walletAddress: "USER_WALLET",
      recipientAddress: "RECIPIENT_WALLET",
      tokenMint: "TOKEN_MINT",
      amount: "12.5",
      sponsorshipRequested: true,
      feeHandlingMode: "charge_separately"
    })
  });

  const review = await response.json();

  if (!response.ok) {
    throw new Error(review.requestId ? `${review.error} [${review.requestId}]` : review.error);
  }

  if (review.policyAction === "block" || (review.requestedSponsorship && !review.sponsorshipApproved)) {
    return {
      status: review.policyAction === "block" ? "blocked" : "sponsorship_unavailable",
      summary: review.explanationBundle.oneLineSummary,
      warnings: review.warnings,
      sponsorshipReason: review.sponsorshipReason
    };
  }

  return {
    status: "reviewed",
    analysisId: review.analysisId,
    safety: review.userSafety.classification,
    sponsorshipApproved: review.sponsorshipApproved,
    prepaidBilling: review.accountCommercialUsage?.billingMode ?? "included"
  };
}

Agent handling rules

1

Discover `/llms.txt` and `/openapi.yaml`, then call the current HTTP API directly. There is no MCP server.

2

Start with the review path for your base URL: direct API origins use `POST /api/analyze-transfer` or `POST /api/analyze-swap`; the public web host uses the proxy paths listed in `/openapi.yaml`.

3

Treat `policyAction`, `userSafety.classification`, `sponsorshipApproved`, and `sponsorshipReason` as server truth, not values to recalculate client-side.

4

For sponsored transfer UX, prefer `client.reviewSponsoredTransfer(...)` or set `sponsorshipRequested: true` with an explicit `feeHandlingMode` on transfer review.

5

Use `x-artax-app-key` for protected developer API access and `x-artax-api-key` when attaching the request to account allowance, prepaid balance, usage, and project scope.

6

When a result is blocked, unsupported, or sponsorship-denied, surface that plainly and stop the signing path.

Funding and pricing

  • Free sandbox use comes first, then prepaid USDC funding becomes the paid upgrade path.
  • Devnet sandbox usage stays included and rate-limited, while mainnet-beta usage is the path that reduces shared prepaid USDC balance.
  • Public pricing stays simple: no monthly fee, usage-only charges, prepaid USDC balances for paid API usage, and a generous free tier before funding is needed.
  • The published supportedTokens list is a curated token-profile set, not the full transfer coverage list; broader SPL review can still analyze unfamiliar mints and return a conservative result when confidence is low.
  • Funding instructions, funding status reads, and funded-advisory key issuance are available.
  • No unsecured SOL funding path is part of the intended model.

SDK starter

The developer layer includes `@artax/sdk`, `@artax/sdk/react`, and `@artax/ui`. Together they cover typed API access, sponsored-transfer review and submit helpers, React hooks for live analysis, browser launch helpers that prefer the add-on and fall back to hosted review, and reusable review modules for embedded flows.

import { ArtaxClient } from "@artax/sdk";

export async function reviewSponsoredTransfer() {
  const client = new ArtaxClient({
    apiBaseUrl: "https://your-artax-api.example.com",
    developerApiKey: process.env.ARTAX_APP_KEY,
    accountApiKey: process.env.ARTAX_ACCOUNT_API_KEY
  });

  const { analysis, decision } = await client.reviewSponsoredTransfer({
    appId: "your-artax-app",
    walletAddress: "USER_WALLET",
    recipientAddress: "RECIPIENT_WALLET",
    tokenMint: "TOKEN_MINT",
    amount: "12.5",
    feeHandlingMode: "charge_separately"
  });

  if (!decision.canContinueToSigning) {
    return {
      status: decision.nextAction,
      summary: decision.summary,
      warnings: decision.warnings,
      sponsorshipReason: decision.sponsorshipReason
    };
  }

  return {
    analysisId: analysis.analysisId,
    preparedTransactionBase64: analysis.preparedTransactionBase64,
    sponsorshipApproved: decision.sponsorshipApproved,
    feeHandlingMode: decision.selectedFeeHandlingMode
  };
}

Keep devnet for testing

  • Devnet is the builder sandbox and remains the sandbox after launch, so teams can keep testing integrations and regressions without touching paid mainnet-beta traffic.
  • Mainnet-beta setup is a create-new-key step, not a silent retarget: keep the devnet key and issue a separate mainnet-beta key for the same project when you are ready for live users.
  • Commercial balance can stay shared at the account level, but devnet stays included and mainnet-beta is the paid path.
  • Teams shipping on Solana devnet can keep Artax in their devnet stack all the way through their own launch validation cycles instead of throwing the sandbox away.

Promotion checklist

1

Bootstrap on devnet with the default project and sandbox key, then prove hosted-review or SDK behavior against your own devnet app.

2

Keep the devnet project alive for partner QA, AI-assisted testing, and post-launch regression checks instead of overwriting it.

3

When launch validation is stable, issue a separate mainnet-beta API key for the same project with the scopes you actually need.

4

Only add prepaid USDC and move into funded advisory or execution-request access when the mainnet-beta project is the one preparing for live traffic.

Hosted review launch

Start with a redirect-style integration that sends a prefilled reviewed intent into the Artax review workspace.

Dashboard-backed account setup

Use the dashboard to inspect balance, usage, projects, API keys, funding instructions, limits, and denials before handing a scoped key to an agent.

Install and launch helpers

The browser add-on gives a fast popup-review surface plus trusted launch helpers. It stays narrower than a universal signing overlay and falls back to the main site when a deeper flow is needed.

Developer references

  • `@artax/sdk`, `@artax/sdk/react`, and `@artax/ui` for typed API access, launch helpers, hooks, and reusable review modules.
  • `apps/partner-demo` for a live example that calls the current API and renders embedded Artax review UI.
  • `/openapi.yaml`, `/llms.txt`, `/llms-full.txt`, and `docs/agents/ARTAX_AGENT_GUIDE.md` for the current public developer references.
  • Private operations indexes are intentionally kept out of the public product navigation.

Keep these boundaries in mind

  • The guided onboarding wizard is real, but it stays limited to the available account, verification, project, key, and funding surfaces.
  • This page is a builder guide, not the final API contract or compatibility matrix.
  • Embedded review is real, but it is not a claim that every partner owns embedded signing end to end.
  • Autonomous execution is disabled by default, and higher-risk execution still requires manual approval.
Artax