Foinse

Build with Foinse.

Accept compute for something you run, or build software that uses a Foinse account. Start with the path that matches what you’re making.

Choose your path

  1. Get paid for a site or API. Use the Toll SDK to put a payment door on your route. Your coding agent can follow the repository setup.
  2. Use a Foinse account in your app. Use the account and ledger API to transfer balances or spend compute.

Test before going live

Start in the sandbox, where every credit and settlement is test data. When the integration works, follow the live setup instructions and keep your first real payments small.

Technical integration details

The credential model

  • Native provider key: provider-issued access to a provider account. A payer presents a capped key to authorize a toll; the recipient never receives it as the product.
  • Quota key: a capped authorization created around a native provider key. It belongs to the payer acceptance arrangement, not to universal Foinse account authentication.
  • FK1: a Foinse-issued bearer credential bound to one Foinse account. It accesses that account's bearer balances for permitted transfers and native inference spending through Foinse's spend path.

Treat every credential as a secret. Never place native keys, quota keys, or FK1 in source control or public client-side code.

Integrating toll acceptance

The Python and Node middleware wraps your paid route and relays a compatible gate. Its documented Door 1 flow is a signed 402 challenge, direct native-key surrender with an idempotency key, and a resulting single-use qtt1 ticket presented to the protected route. Package limits and source-only installation are described in the Toll SDK.

Door 2 uses the exact charge as verification and the committed payment movement event_id as the access grant. Do not require a Door 1 qtt1 ticket on that path. Neither access grant is the creator's bearer token balance.

Integrating account and ledger access

The API is REST over HTTPS with JSON request and response bodies. Use FK1 only where an endpoint specifies Foinse account authentication. The /v1 and /v2 route families carry different stability expectations; do not infer a monetary door, provider, or credential type from the version string alone.

Settlement model

Provider-token balances retain their native denomination. Foinse issues no house asset and does not supply inference. A settled line satisfies payer debit = recipient credit + protocol fee. The recipient receives the full listed amount, and the separately disclosed processing toll is added on top. No 0.8x face rule or fixed 20% discount is current policy.

Grades and operational status

Responses may carry live, live-attested, attested, fixture-mechanism, or fixture evidence grades. Check the grade and route status before acting. A proxied route or a live proof in another lane does not by itself make every operation generally available.