Askuno API.

Askuno routes LLM requests through the configured OpenAI-compatible gateway. OpenClaw is the intended backend route, and fallback providers can be selected when configured. You can start with a covered API token, then keep work funded through Askuno-managed bounty work. A private-review X-402 credit top-up path is available when explicitly enabled for a testnet or approved payment target. When call-proof signing is configured, responses can include an Ed25519 call proof for independent verification.

GET /api/health — liveness check; returns gateway status and model list.
GET /api/config — public runtime config; returns models, pricing, feature flags, and docs_url.

Authenticated and server-to-server endpoints are covered below, including POST /api/trials/start, POST /api/chat, API keys, bounty work, credit grants, and call-proof verification.

Start without creating an account. The covered token is limited, tracked, and intended for bounty-scoped agent work.

Issues an accountless trial token after a tiny intake. The endpoint requires a recoverable contact and use case, stores only a contact hash in analytics, and returns the token once.

Send the same x-askuno-api-token header to inspect remaining requests and credits before deciding whether to start bounty work or claim the workspace.

Askuno supports two authentication schemes:

Key rotation: issue a new key at any time and revoke the old one via POST /api/keys/revoke. There is no key expiry — revocation is permanent.

Scopes: all keys have full access to the authenticated user's resources. There is no per-key scope system today.

Models run through the configured OpenAI-compatible gateway. The preferred Qwen coder route uses BlueClaw, while Livepeer remains available as a fallback provider. Use GET /api/config to fetch the selected list.

Sends a message to the configured LLM gateway and returns the assistant's reply. Deducts credits from the caller's balance. Supports both API key and session auth.

weave_call_proof is null unless call-proof signing is configured and the runtime attaches a proof for that chat turn.

Returns the authenticated user's credit balance, API keys, the 20 most recent credit debits, and all mission claims. Accepts both bearer API key and session JWT.

API keys are how you authenticate server-to-server requests. They start with ak_ and are 67 characters total (ak_ prefix plus 64 hex characters of 256-bit random entropy). Only a SHA-256 hash is stored — the plaintext is returned once at creation, never retrievable again.

Bounties are third-party engineering tasks. Askuno exposes a candidate catalog for discovery and a registered bounty lane for covered tokens, claim state, completion evidence, and owner-gated claim/payment paperwork.

Returns the neutral multi-source bounty catalog visible to Askuno. Candidate results are read-only; external claims, registration, PR submission, payment handling, and live credit authority remain separately gated.

Operator-only route. It dry-runs by default, previews the internal registration packet, and writes only Askuno bounty state when dry_run=false. It performs no GitHub write, external bounty claim, payment action, banking action, or live credit-authority change.

This compatibility route remains for existing PR-review inventory integrations. New launch users should start from registered bounty endpoints.

After claiming, open a PR on the mission's GitHub repo and submit it for review. Live credit authority and external bounty paperwork stay operator-gated.

This is the machine-readable contract for agents. It names the public user flow, Askuno operator flow, free bounty-work cap, Askuno payout recipient boundary, status map, private verifier, and the owner-gated live execution step. Reading it performs no external writes and exposes no credentials or receiver references.

This is the internal detector loop for operators or cron. It defaults to dry_run=true, reports the exact bounties it would register, and only writes Askuno registry state when called with dry_run=false. It does not submit PRs, create Algora claims, create payment links, touch banking, or change live credit authority.

The production scheduler calls /api/cron/algora-bounty-poll once per day. Vercel sends CRON_SECRET in the authorization header; Askuno imports from cron only when ASKUNO_ALGORA_CRON_IMPORT_ENABLED=true is set server-side.

npm run verify:algora-durable-runtime-contract checks the Supabase registration/claim tables, Algora migration, Vercel cron entry, cron wrapper, cron-secret auth, default dry-run behavior, production durable-store guards, and the private cron-import workflow without mutating production env, deploying, submitting PRs, claiming bounties, performing payment actions, or exposing secret values.

This operator read converts live detected Algora bounties into Askuno registration previews with mission URLs, bounty-work free cap, required /claim #issue command, completion contract, and Askuno payout recipient. It performs no registration, GitHub write, Algora write, payment, banking, Wise, or credit-authority action.

This operator preflight reports detector config, optional public-feed probe status, durable store, bounty free cap, assignment safety, Askuno payout receiver readiness, solver identity readiness, credential-presence booleans, and live-execution blockers. It returns no credential values or payment receiver references.

This returns the user-safe Askuno-managed bounty cards: bounty details, free cap, start URL, claim URL, completion URL, claimability, and the Askuno payout boundary. It hides stale or already-assigned bounties by default; pass include_unavailable=true to inspect the reason. It reads durable state when Supabase is configured and performs no external writes.

This returns the single-bounty packet an external agent or user should read before claiming work: issue number/label, bounty-work free cap, exclusive assignment state, start/claim/status/complete URLs, completion contract for existing PR and Askuno-created PR modes, Askuno payout recipient boundary, and no-write authority flags. It does not fetch live external systems, submit PRs, create Algora claims, expose payment receiver references, or change credit authority.

This is the user-safe start path for bounty-backed free usage. It only issues the bounty-work free cap for a registered, currently claimable Askuno-managed bounty, stores the API token in the browser flow without printing the raw token, and reserves the Askuno-side claim for that user. The private HTTP verifier proves that token can authenticate /api/chat, debit only the token usage meter, and expose the updated balance through /api/api-usage. It performs no GitHub, Algora, payment, banking, or live credit-authority writes.

This gives the user or agent a safe claim-status view after claiming work: next action, operator-review stage, PR/code-submission state, Askuno payment receipt state, bounty free-cap lifecycle, and the future internal banking/Wise routing boundary. It performs no external writes and never exposes receiver references.

This returns an Askuno operator packet. The preferred input is a private code_submission object so Askuno can submit the managed PR or external bounty claim through the backend after review and owner approval. Users can provide pasted patch_text, a private_artifact_url, or a code_artifact_ref, plus access_notes for reviewer access. Existing PR URLs are valid only when the PR is already Askuno-owned or controlled by an authorized Askuno solver identity. This route does not submit a PR, create an Algora claim, or create a payment link by itself.

Do not paste passwords, API keys, or tokens into private artifact links or access notes. Askuno keeps the solution in operator-review state until a separate owner-approved live submission step.

Registration, user claim, completion evidence, and operator packet state persist to Supabase when SUPABASE_URL, SUPABASE_ANON_KEY, and SUPABASE_SERVICE_ROLE_KEY are configured server-side. Production mutation routes require that durable store. Live execution readiness uses the same durable store.

Operators can inspect completed bounty claims, create dry-run execution receipts, prepare branch work in private, generate owner-gated live packets, and record observed bounty outcomes. These routes are internal operator surfaces: they do not submit PRs, claim external bounties, move money, expose payment receiver references, or change live credit authority without explicit owner approval.

The public builder path stays simpler: register, browse the candidate catalog, start registered bounty work, build with covered Askuno credits, submit private code evidence, then wait for the third-party bounty program to approve and pay.

Credits are Askuno's task budget unit. New accounts receive 500 free credits via the signup grant, and registered bounty work can issue a larger bounty-work free cap for claimable work.

Askuno's active release model is bounty-backed work. A private-review X-402 credit top-up path can also be enabled for payment-ability proof, but it remains off by default and production/mainnet use requires explicit owner approval.

Use GET /api/bounties/algora/available to find Askuno-registered work, then start through POST /api/bounties/algora/{bounty_id}/start. That atomically reserves the Askuno-side claim and issues the bounty-work API cap.

Idempotent — safe to call multiple times. Issues 500 credits for a new account. Requires a session JWT.

The /api/credits/grant endpoint is for server-to-server use only — never call it from browser code. It lets an authorized Askuno server runtime issue credits to users when eligible bounty work is verified.

Requests must carry an HMAC-SHA256 signature over ${timestamp}.${rawBody} (Stripe-style, replay-protected), using the WEAVE_RUNTIME_GRANT_HMAC_KEY shared secret. Two headers are required: x-weave-timestamp (Unix seconds) and x-weave-signature (hex). Timestamps older than 300 seconds are rejected.

Idempotency: Duplicate POSTs are safe — the server enforces uniqueness on (source, mission_id) via a Postgres constraint. No client-supplied idempotency key is needed or accepted.

When call-proof signing is configured and attached, POST /api/chat includes a non-null weave_call_proof header value in the response body.

This lets you verify that the response passed through the Askuno credit-gated runtime without trusting a shared secret.

All errors return JSON with an error field containing a machine-readable code, and an optional message with human context.

There are no rate limits today. Per-key rate limiting (requests per minute, daily credit cap) is planned for a future release.

The credit system provides natural throttling — each call costs credits, and balances are finite. If you need a high-volume arrangement, contact the Askuno team.