How to Use CardanoWall Without the Website

You can use CardanoWall without ever opening the website. The same Proof of Existence records can be created, published, and verified from a command-line tool, an SDK in your application code, a gateway API, a desktop app, or a service you run yourself. The website is one front end onto an open standard — Label 309 — and the standard is what actually matters.

That distinction is the whole point. Proof of Existence is often not a one-off human action. It belongs inside a build pipeline, a compliance routine, an AI provenance system, a legal evidence workflow, or a product someone else builds. None of those should require a person clicking through a single web UI.

What does the website actually do?

The website makes Proof of Existence approachable. It gives you a visual composer, an account and balance view, record pages, identity management, an upload flow, and guided publishing. For most people, that is the right place to start.

But it should not be the only way to use the standard. If a proof only works when a human clicks through one interface, it cannot become infrastructure. Companies need automation. Developers need APIs and SDKs. Operations and security teams need repeatable, scriptable workflows. Some users want their records and files on their own machine. Some operators want to run the whole pipeline themselves.

The web app is the front door. It is not the whole building.

What are the other ways to use it?

There are several, and they all converge on the same artifact — a standard Label 309 record anchored on Cardano that anyone can verify independently:

the CardanoWall web app;
the open-source cardanowall command-line tool;
the official SDKs (TypeScript, Python, Rust) for application code;
a Label 309 gateway API, reached with a per-account token;
CardanoWall Desktop, the open-source local-first client;
a gateway you self-host;
your own product built on top of a gateway.

The interface can change. The proof format does not. All of this code is open source under github.com/cardanowall, licensed Apache-2.0, with the specification text under CC-BY-4.0.

When should I use the gateway API?

Use the API when publishing or reading proofs needs to be part of a system rather than a manual step. For example:

a SaaS product creates a proof for each customer document;
a build pipeline publishes release evidence after every build;
an AI platform anchors batches of generated outputs;
a compliance system publishes a daily control snapshot;
a workflow seals evidence for specific recipients;
an internal dashboard reads publish status and account balance;
a partner integration submits records without touching the CardanoWall UI.

The API path lets your software call a gateway directly while you keep your own user experience. CardanoWall's own web app and worker reach the gateway through exactly these public endpoints — there is no private door, so anything the reference product can do, you can do too. If you want to go deeper here, see build on the CardanoWall API.

How do API tokens and scopes work?

A gateway distinguishes two kinds of credential, and keeping them separate is the most important thing to get right.

Account tokens act as one of your users. Your backend mints a short-lived token for a specific account and the call proceeds under it: request a quote, upload content, publish, read that account's balance. These are the tokens — and the API keys built on the same model — that belong in scripts, CI jobs, and integrations. They are deliberately narrow. The current scope set is small and purpose-built:

poe:create — request quotes, upload content, publish records;
poe:read — read records and publish status;
inbox:read — read the encrypted inbox sync bookmark;
account:read — read the account balance.

That is the entire programmatic surface, and it is scoped on purpose. A read-only dashboard widget needs only account:read. A publishing job needs poe:create. Neither needs the other. There is intentionally no decrypt-on-the-server scope: sealing and unsealing are client-side operations, so recipient private keys never reach a gateway and no API key could ever authorize the server to read sealed content for you. A CI job should likewise never hold a user's Identity Seed unless local signing is a deliberate part of your own design, under your own controls — seeds and private keys stay on the client by design and are not something a gateway ever sees.

Operator credentials are the second kind, and they are not API keys. They authorize the control plane — provisioning accounts, applying balance adjustments when your billing collects money, setting margins, minting the account tokens above. They must live only on a trusted backend, never in a browser, a mobile app, or a script. A leaked account token should be a short-lived nuisance; a leaked operator credential would be a real incident.

The rule of thumb: hand clients the narrow account-scoped token they need, and keep operator authority behind your own backend.

When should I use the CLI?

Use the command-line tool when a proof belongs in a script. The cardanowall binary is gateway-agnostic and raw-seed-first, which makes it a natural fit for:

verifying a record locally, without opening any website;
building and checking Merkle proofs over many files;
signing records;
submitting records from automation;
inbox sync and trial-decryption from the terminal.

The CLI matters most because it keeps Proof of Existence close to the systems that generate the artifacts. A build pipeline can hash its outputs and publish a record as part of the release. A compliance job can commit a daily manifest. A local user can verify a record offline. The website is great for people; the CLI is great for repeatable operations. For patterns and examples, see use the CLI in automation.

When should I use an SDK?

Use an SDK when Label 309 should be part of your application. The TypeScript, Python, and Rust SDKs help with constructing records, hashing content, verifying transactions, signing off-host, sealing and decrypting payloads, deriving identity from a seed, and talking to any gateway.

The point of having three SDKs is not convenience — it is interoperability. They are byte-identical twins, validated against the same canonical test vectors, so a record published or signed by one verifies identically under the others. That is how an open standard stays an open standard instead of fragmenting into mutually incompatible "compatible" formats. One useful property worth highlighting: the standalone verifier needs only the transaction metadata, optionally the content bytes, and a public Cardano explorer — no issuer server sits in the trust path.

When should I use Desktop instead of the website?

Use the desktop app when local ownership matters. CardanoWall Desktop is an open-source, cross-platform, offline-first client built in Rust with Tauri on top of the Rust SDK, and it works like a mail client: it gives you

local, encrypted identity vaults;
offline access to everything already synced;
sealed-inbox discovery and cached ciphertext on your own machine;
local search over the public record index;
multiple identities and your choice of gateway provider.

The website stays fast and convenient, while the desktop app is the better home when you want your records, identities, and cached files to live locally and keep working with no network. For many people the answer will be both. There is more on the design in CardanoWall Desktop and offline proofs.

When should I self-host a gateway?

Self-host when you want to operate the publish pipeline yourself — for compliance, cost structure, volume, data-handling policy, infrastructure control, or product strategy.

A self-hosted gateway still publishes standard Label 309 records; the difference is that you run the service that quotes, uploads, submits, confirms, indexes, and accounts for publishing. The gateway is an open-source Rust single binary plus Postgres, with its own Cardano transaction builder that builds, submits, confirms, handles chain reorganizations, and auto-refunds on permanent failure.

Self-hosting is not "free." You still pay the underlying Cardano and Arweave costs, and you take on the operational responsibility for running it. What you remove is any dependency on a hosted CardanoWall gateway for publishing. See run your own gateway and what is a Label 309 gateway?.

Can I build my own product on a gateway?

Yes — and that separation is exactly why the gateway is its own layer, distinct from the web app. You can build a notarization product, an evidence portal, a compliance archive, a publishing tool, an AI provenance service, or an internal dashboard on top of a Label 309 gateway.

The gateway owns the base plane: chain, storage, pricing, the shared on-chain records index, balances, and publish status. Your product owns the vendor plane: users, billing, UI, workflows, notifications, support, and whatever product-specific meaning you put on top of records. That lets far more products share one proof standard without every team having to become a Cardano transaction and storage operator. The walk-through lives in build on a Label 309 gateway.

Can I verify without CardanoWall at all?

That is the goal, and it is the strongest reason the rest exists. Verification must not depend on the CardanoWall website. Anyone should be able to read the transaction metadata, reconstruct the Label 309 record, validate its structure, check any record signatures, recompute the content hash, and — with the right key — decrypt a sealed record locally.

A proof that only one website can verify is a weak proof. Open SDKs, an open CLI, and an open specification are what make a Label 309 proof verifiable by anyone, including third parties who never touch CardanoWall. If you want to do this yourself, start with verify a Label 309 record.

What about pricing?

Changing the interface does not remove the underlying cost. Whether you publish from the website, the desktop app, the CLI, the API, or your own product, someone still pays real Cardano transaction fees plus any storage used for files or ciphertext. A hosted gateway adds a margin on top to cover operations, funding, infrastructure, and support, so the price is cost-pass-through plus that margin.

If you use CardanoWall's hosted gateway, you use its prepaid-balance and pricing model. If you self-host, you operate and fund your own gateway directly. Either way, the standard makes the record portable — it does not make blockchains or storage free. The reasoning is spelled out in why publishing has a price.

One important limit

A Label 309 proof shows that specific bytes existed by a specific public time, and that they have not changed since. It does not prove who authored the content, who owns it, whether it is true, or whether anyone has rights to it. A sealed record keeps its plaintext readable only to the intended key holders, but it cannot guarantee anonymity and cannot stop a recipient from leaking the plaintext once they have decrypted it. Keep that boundary in mind whatever interface you publish from.

The short version

CardanoWall is not only a website. The website is the easiest human interface; the gateway is the publishing layer; the CLI and SDKs are the developer surfaces; the desktop app is the local, offline-first client; self-hosting is the operator path. They all produce the same thing: a standard Label 309 record that can be verified outside the interface that created it.

Choose the interface that matches the work. Use the website for people, the CLI for scripts, the SDKs for products, the API for systems, and a self-hosted gateway when vendor independence or operational control is what you need.