Complete features,
delivered as source.

Gives users an account they reach with a link sent to their email, with an optional password and recovery. Your server keeps every account and session.

In the product

Users enter their email and open the link it sends; the first link creates their account. Passwords are an optional fallback with their own reset, and users can sign out or delete their account.

Across the API

POST /auth/magic-link sends a link and /auth/verify exchanges it for a session. POST /auth/password/reset/request and POST /auth/password/reset recover a password, GET /me returns the signed-in account and POST /auth/logout signs out.

On the server

Stores sign-in tokens only as hashes, spends each one with a single conditional write, and creates the session in the same transaction. Emailed links always use your validated public origin.

What it guarantees

• Each sign-in link works once and expires quickly
• A password reset signs out every session
• Unknown accounts take as long to check as real ones

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

The shared flow every provider uses. Users sign in with an account they already have or connect one to the account they use now, and a matching email never joins two accounts by itself.

In the product

The sign-in screen lists the providers your server offers. From Account security, users connect another way to sign in or remove one.

Across the API

GET /auth/providers/available lists providers without account data. POST /auth/external/{provider}/start begins a sign-in and POST /auth/external/{provider}/complete finishes it once, with the PKCE verifier only the client holds. GET /auth/providers and DELETE /auth/providers/{identityId} manage linked accounts.

On the server

Keys each linked account by provider and immutable subject, keeps authorization state hashed and single-use, discards provider tokens, and runs your admission rules inside the sign-in transaction.

What it guarantees

• A matching email never links accounts by itself
• Provider access and refresh tokens are never stored
• A refused sign-in writes nothing

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Adds Sign in with Apple. Your server signs short-lived client assertions with its own P-256 key and accepts an Apple ID token only when every claim matches.

In the product

Users tap Sign in with Apple and approve it with their Apple Account. The app passes the identity token Apple returns to your server, which checks it before any session exists.

Across the API

POST /auth/apple signs in with an Apple identity token, POST /auth/apple/link connects Apple to the signed-in account, and POST /auth/apple/notifications receives Apple’s account events.

On the server

Requires Apple’s exact issuer, your product’s audience, an RS256 signature, a valid lifetime and the transaction’s nonce. Partial or malformed key configuration stops the server at startup.

What it guarantees

• The private key never leaves your server
• Every ID token must carry its transaction’s nonce
• The local stand-in runs only in development

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Adds Sign in with Google through OpenID Connect. Your server accepts a Google ID token only with the exact issuer, your audience, a valid signature and lifetime, the transaction’s nonce and a verified email.

In the product

Users choose Sign in with Google. The app passes the ID token Google returns to your server, which checks it before any session exists.

Across the API

POST /auth/google signs in with a Google ID token and POST /auth/google/link connects Google to the signed-in account.

On the server

Requires an allowed algorithm, Google’s exact issuer, your audience, a valid signature and lifetime, and the transaction’s nonce. A token from the app must name one of your client IDs and carry the SHA-256 of the nonce the app kept.

What it guarantees

• Client credentials stay with your server
• No Google token is stored
• Partial configuration stops the server at startup

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Adds Sign in with GitHub. The account’s numeric ID is the identity, and only an email GitHub has verified can create an account.

In the product

The app opens GitHub’s authorization page in an ephemeral browser session, asking for user:email alone. Your server finishes the sign-in.

Across the API

Adds no routes of its own. It signs in through the provider flow at /auth/external/github/start, and only the server redeems the code.

On the server

Holds the client secret, redeems the code, reads GitHub’s verified-email endpoint and drops the access token once the profile is loaded.

What it guarantees

• Login names and emails are never identity keys
• Only a verified email creates an account
• A matching address links only from the account holder’s session

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Connects any OpenID Connect provider, such as the one your organization runs. You configure each endpoint explicitly, and only allowed signatures are accepted.

In the product

Users choose Sign in with your organization, continue on their provider’s page and come back through the shared provider flow.

Across the API

Adds no routes of its own. It signs in through the provider flow at /auth/external/oidc/start.

On the server

Uses only the issuer, authorization, token and key endpoints you configure, never runtime discovery. Accepts HTTPS endpoints, the exact issuer and audience, RS256 or ES256 signatures, a valid lifetime and the transaction’s nonce.

What it guarantees

• Endpoints are explicit configuration, never discovered
• Plain-HTTP endpoints are refused in production
• The development provider answers only on loopback

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Adds passkeys, authenticator codes and one-time recovery codes to the sign-in your product already has. Password, magic link, external and enterprise sign-in all pass one check before any session exists.

In the product

Users add a passkey with Face ID or Touch ID, scan an authenticator QR code, keep their recovery codes, and answer a code prompt when they sign in.

Across the API

A sign-in that needs a second factor answers 403 identity.assurance.mfa_required with a sealed, single-use ticket. POST /auth/mfa finishes it.

On the server

Checks each passkey’s origin, signature and counter, encrypts authenticator seeds with a host-owned key, hashes recovery codes, and creates the session only after the code is accepted.

What it guarantees

• No session while a second factor is pending
• Recovery codes are shown once, hashed and spent once
• Security changes need a sign-in from the last ten minutes

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Shows users every device signed in to their account and a history of security events. They can sign out one device or every other device, and your server’s session table stays the only authority.

In the product

Lists signed-in devices with coarse labels and when each was last used, marks this device, confirms before signing one out, and shows recent security events.

Across the API

GET /auth/sessions and GET /auth/security-events return the account’s devices and history. DELETE /auth/sessions/{sessionId} signs one device out. The web adapter adds the same controls under /settings/security.

On the server

Ends live authority in the same transaction as the history entry, keeps only token hashes, and never stores raw IP addresses or full user-agent strings.

What it guarantees

• A revoked session stays revoked
• Signing out every other device keeps this one
• History is append-only and keeps safe summaries

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Asks for proof that a person or a genuine app is behind a sensitive action. Browsers prove it with Cloudflare Turnstile and Apple apps with App Attest, and each proof is spent on one action.

In the product

When a guarded action needs proof, the client completes a Turnstile check in the browser or an App Attest assertion on the device, then sends the action again.

Across the API

A refused request answers challenge.required. POST /challenge/proofs trades a verified proof for one clearance, and the retry uses a new Idempotency-Key.

On the server

Validates Turnstile through Siteverify with your secret, verifies App Attest against Apple’s pinned root without a network call, and binds each proof to one resource that it can clear once.

What it guarantees

• One proof clears one resource, once
• Production refuses the development provider and keys
• Raw tokens, payloads and addresses are never stored

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. App Attest is tested against synthetic attestations. An end-to-end run with a real Apple Developer team is still to come.

Turns product signals and provider scores into a decision with a named reason. Your rules stay the authority; a provider’s score is only an input.

In the product

Your app can read the active policies and the signed-in account’s own decision evidence, and dry-run a policy you mark previewable.

Across the API

GET /risk lists policies and signals. POST /risk/evaluate dry-runs a previewable policy against the signals you send and records nothing. Enforcement stays inside server-owned operations, because a client cannot assert a trusted product signal.

On the server

Evaluates versioned rules in a fixed order with a fail-closed default, stores only a signal digest and a safe reason code, and purges expired evidence every hour.

What it guarantees

• Unknown, stale or out-of-range signals fail closed
• Provider scores are inputs, never authority
• Evaluation is separate from enforcement

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Gives each sensitive operation a named limit with its own window, cost and failure posture. Keys come from trusted request context, so callers never choose what they are counted as.

In the product

No screens of its own. It sits behind actions users already take, including the challenges above.

Across the API

Adds no routes. A refused action returns bounded remaining and retry information, and never reveals the key it was counted under.

On the server

Every adapter, on SQLite and PostgreSQL alike, decides with one conditional upsert so concurrent requests cannot overspend, stores only key digests, and keeps one current window per operation and key.

What it guarantees

• Network limits always include a resource
• Key dimensions never substitute for each other
• A store outage follows the registered posture

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Connects a team’s verified domain to its organization’s OpenID Connect provider. People from that domain sign in there and join the team, and the organization’s directory adds and removes them over SCIM 2.0.

In the product

Users enter their work email and the sign-in screen offers their organization’s provider by name. In a browser, the organization sign-in page sends them to it with their address filled in. Owners set up the connection through the API; the supplied screens cover signing in.

Across the API

POST /auth/enterprise/discover finds the provider for a work email. PUT /teams/{teamId}/enterprise saves a connection, POST /teams/{teamId}/enterprise/token rotates its SCIM token and POST /teams/{teamId}/enterprise/disable turns it off. The directory drives /scim/v2/Users and /scim/v2/Groups.

On the server

Checks the verified domain and its holder again at every discovery, sign-in and SCIM call, runs the sign-in policy inside each sign-in, and reports membership changes through team hooks. SCIM requests are bounded and stay outside the product API contract.

What it guarantees

• Local accounts and sessions stay authoritative
• A deactivated person is signed out everywhere
• SCIM tokens are shown once and stored as hashes

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Federation uses OpenID Connect. SAML providers and sign-in started from the provider’s own portal are not supported yet. Single sign-on proves identity and can establish team membership; it does not itself purchase or assign paid developer access.

Teams with three roles. Owners run the team, admins manage its members and members take part. Every team always keeps at least one owner.

In the product

Users create a team, see who is in it and what role each person holds. Owners change roles and remove people, admins remove members, and anyone but the last owner can leave in their own session.

Across the API

POST /teams creates a team and GET /teams/{teamId}/members lists its members. PUT /teams/{teamId}/members/{memberId} changes a role, DELETE removes someone and POST /teams/{teamId}/leave leaves. Deleting a team takes its owner typing its slug.

On the server

Rechecks the caller’s role inside each write and encodes it into the role-change and removal queries, so the last owner can never be removed or downgraded, even through direct SQL or account deletion.

What it guarantees

• Every team keeps at least one owner
• Admins never create, remove or promote owners
• A retried create answers the same team

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Owners and admins invite people by email. The invitation opens in the app or a browser, and only the person signed in with the invited, verified address can join or decline it.

In the product

Managers send, resend and revoke invitations and see when each one expires. The invited person reviews the team and role, then joins or declines. A browser shows the same choice to someone without the app.

Across the API

POST /teams/{teamId}/invitations invites, .../resend sends a fresh link and DELETE .../{invitationId} revokes. The recipient answers through POST /invitations/review, /invitations/accept and /invitations/decline.

On the server

Stores each invitation and the intent to mail it in one transaction and sends mail only after it commits. Acceptance rechecks the verified address, expiry, revocation, role and existing membership in a single write.

What it guarantees

• Tokens are single-use and stored only as hashes
• Resending ends the previous link
• Only owners invite admins

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Named developer assignments backed by explicit organization funding, separate from owner, admin and member roles.

In the product

The supplied SwiftUI section shows purchased, assigned and available seats, paid-through time and each developer’s current or retained historical access. Authorized managers review assignment, removal and reassignment.

Across the API

GET /teams/{teamId}/seats reads a product’s capacity and revision. Assign, unassign and reassign operations bind the exact reviewed revision and a durable mutation identity; direct calls recheck the caller’s role.

On the server

Applies verified capacity evidence and serializes assignment changes with team membership. Retries retain the business identity. Changing membership or funding revokes current access while preserving eligible historical rights.

What it guarantees

• A team role is not a paid developer seat
• Stale revisions refuse without overwriting another change
• Personal purchases remain independent

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Seat allocation does not create a subscription. Your product supplies its licensed product identity, verified funding evidence, checkout and renewal policy. The native section and API are supplied; adapt the browser presentation to your product.

Fine-grained permissions behind each role. Your product declares every permission and role in source; a team’s own roles may only hold permissions you registered.

In the product

Owners pick each person’s role from the roles the team offers. The app offers only the actions a person’s role allows, and the server decides either way.

Across the API

GET /teams/{teamId}/roles lists the roles a team offers and the permissions they grant. PUT /teams/{teamId}/role-assignments/{memberId} assigns one and DELETE ends it.

On the server

Denies every unknown permission, role, resource kind and missing membership. Decisions carry stable reason codes, never sensitive attributes, and every change is authorized again where it happens.

What it guarantees

• Unknown means denied
• Nobody hands out a permission they lack
• An owner’s role is never reassigned

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Versioned policies your product registers in source, each with test vectors that must pass before it serves traffic. A policy that allows by default is rejected.

In the product

Users see the outcome where a policy applies: an action held for review or refused with a reason. The supplied screens do not edit policies; they change with your source.

Across the API

GET /policy/decisions reads an account’s newest decisions and the evidence behind them. A flow run is refused by kind and never reads why a policy held it.

On the server

Evaluates rules by priority in a fixed order and writes append-only evidence with the exact policy digest, in the same transaction as the operation it governs.

What it guarantees

• Defaults are deny, review or hold
• Evidence commits with the operation
• Inputs never carry credentials

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

An append-only record of who changed what, kept per owner and per team. Each record is chained to the one before by hash, so anyone holding a past head can verify the trail offline.

In the product

Owners read the latest security-sensitive changes on the Activity page and export them. With a signing key, an export carries a signed checkpoint.

Across the API

GET /activity lists recent changes and GET /activity/export exports a trail: the account’s own, or a team’s its current members read. GET /activity/verify checks a range, and GET /activity/keys publishes the signing keys to pin.

On the server

Records each team change in the same transaction as the change. Records cannot be updated or deleted, and members appear under a pseudonym that erasing their account makes unreadable while every hash still verifies.

What it guarantees

• Records never change after they are written
• Erased users stay erased
• Checkpoints verify against a pinned key

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. A chain proves nothing was changed, removed or reordered since a head someone kept elsewhere. It cannot prove the honesty of an operator who controls the database and rewrites every hash.

Records each account keeps on its devices, a change feed ordered by one sequence, and an offline queue whose every mutation is applied once. A conflict comes back with the server’s copy; it is never merged for you.

In the product

Users edit notes without a connection, see how many changes wait to sync and sync when they choose. When another device changed the same note, the notebook keeps both versions as separate notes.

Across the API

POST /sync/push applies up to 200 mutations in order, once per mutation ID. GET /sync/changes?since= reads the account’s changes after a cursor and GET /sync/records/{collection}/{recordId} reads one record. The same routes under /sync/teams/{teamId} serve a team’s records to its current members.

On the server

Applies a mutation only against the version the device last saw. On the account routes a conflict answers with the server’s record, and on team routes the client reads it again with membership checked. The server never merges bodies. Team routes check current membership inside the transaction, and sync stays off until the product says who may use it.

What it guarantees

• A replayed mutation returns its recorded outcome
• The change feed never rewrites history
• Sync fails closed until the product allows it

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite

Sync keeps a device's local copy current, offline included. A web or React product reads the server directly and keeps no local copy to sync.

Known limit. Records are bounded JSON objects, not files: a record may name a stored file’s key. Sync does not push changes to devices; each one pulls from its cursor.

Typed topics scoped to a tenant before a resource, delivered as server-sent events on every starting point, with resumable cursors, one coalescing publisher and a Swift stream client.

In the product

A change made in one place appears in the others without a refresh, because open screens hear about it and read it again. A dropped stream reconnects on its own, with growing, jittered waits.

Across the API

GET /realtime/{topic}/{resource} streams text/event-stream to a signed-in caller and resumes with Last-Event-ID. The web and React starting points add a WebSocket and a presence list at /realtime/{topic}/{resource}/presence.

On the server

Publishes a minimal notice only after the change commits, through one Publisher that sends at most one event per topic, resource and type each second by default. Sessions and topic access are checked again while a stream stays open, and a slow subscriber is disconnected rather than blocking anyone.

What it guarantees

• Every stream is scoped to a tenant first
• Events are signals to refetch, not data
• A restored database tells clients to resync

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. The API starting points fan out within one process, so run a single instance. The web and React starting points can fan out through Redis, whose URL stays with the host.

Private product requests, requester history, operator review and independently curated public plans, installed as owned source.

In the product

People submit private ideas, read their own request history and follow published plans. Operators use separate review and curation views. Internal notes and other customers’ requests stay out of personal history.

Across the API

Owner operations read and submit private requests. Verified operator sessions manage reviews and curated plans. A public read returns only deliberately published plans.

On the server

Stores stable request identities, exact revisions and atomic review history. SQLite and PostgreSQL serialize quota and order changes. Account erasure removes private requests while preserving independent plans.

What it guarantees

• Request bodies and internal notes are never automatically public
• Same-intent retries retain the request identity
• New release claims require product evidence

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Configure verified product operators and a release-evidence resolver. There are no votes, public comments, automatic publication or promised delivery dates. Support conversations remain separate.

One subscription per account, whichever provider bills it. Customers start a plan through checkout, manage it in the provider’s portal and cancel it. A hosted provider’s changes arrive as signed events your server verifies.

In the product

Customers see their plan and its price, upgrade through checkout and return to Free after confirming. A plan another provider bills, such as the App Store, is managed in that provider’s settings, and the app says so.

Across the API

GET /billing reads the plan and subscription. POST /billing/checkout starts checkout, POST /billing/portal opens the customer portal and POST /billing/cancel cancels. Providers report changes to POST /integrations/billing/webhook.

On the server

Verifies each provider event’s signature and records it once before the subscription changes. Checkout, the portal and canceling act only on the caller’s own account and admit only the person’s own session unless your product widens them.

What it guarantees

• One account never holds two live subscriptions
• Automations and visitors never change a plan
• Provider secrets and payloads are never stored or shown

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Local billing is for development only. Production needs your own Stripe credentials and price identities, which stay with the host.

Features and allowances derived from each plan, decided in one place. A missing, inactive or unknown subscription falls back to the plan you register for it.

In the product

Customers get the features and allowances their plan includes. Your operators can grant one account an exception, with a reason, once the owner’s approval allows it.

Across the API

GET /entitlements lists each feature for the calling account: whether it is on, its limit and why. Operators set or clear one account’s override through POST /entitlements/overrides and .../clear, once the owner’s approval allows it.

On the server

Every capability that decides from plans asks the same entitlement service, so billing never bypasses a decision. Every refusal fails closed and shows nothing about another account.

What it guarantees

• Billing selects a plan, never bypasses a decision
• Only listed operators set overrides
• An override commits with its record or not at all

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Usage counted against each plan’s allowance, with a ceiling customers may set lower for themselves. Each use is recorded once, and work whose size is known only afterwards can hold its share first.

In the product

Customers see what they have used this period, what their plan includes and the ceiling they chose. When work would pass the ceiling, the app says whose limit stopped it.

Across the API

GET /usage reports each metric for the period. PUT /usage/{metric}/spend-limit sets a ceiling and DELETE removes it, so the plan’s allowance decides again.

On the server

Locks the period’s counter before every limit decision, so simultaneous requests cannot pass the limit together. Each usage write carries an idempotency key, and a plan that cannot be charged more never passes its allowance.

What it guarantees

• Each use is counted once
• Concurrent work cannot overrun a limit
• Usage events are the durable record

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

StoreKit 2 purchases your server verifies before it grants anything. Apple’s server notifications apply once and in any order, and the subscription’s state projects into billing, so every client sees the same plan.

In the product

Customers buy Pro in the iPhone app’s storefront and restore earlier purchases. The app posts each signed transaction to your server, which grants the plan. Linklet’s browser account page then shows Pro as bought in the App Store, which is one way to show it.

Across the API

GET /commerce/appstore/account-token gives the app the token it attaches to a purchase, and POST /commerce/appstore/transactions posts a signed transaction. GET /commerce/appstore/entitlement reads the App Store state and POST /commerce/appstore/reconcile asks Apple for it again. Apple reports changes to POST /integrations/appstore/notifications.

On the server

Verifies every signed payload against Apple’s root, the product’s bundle ID and its environment before any state changes, and applies inputs in signing order. A grace period keeps access, billing retry does not, and a refund revokes it.

What it guarantees

• Another account cannot claim a subscription
• A repeated notification changes nothing
• Production refuses test signatures

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite

App Store purchases happen only inside an Apple app, so a web or React product has no transaction to verify. An Apple product that also serves a browser keeps its purchases on the Apple stack.

Known limit. App Store purchases happen only inside an Apple app, so the web-only starting points do not include them. Reconciliation needs your App Store Server API key, which stays with the host.

License keys for apps you sell directly, issued from billing plans. Each key activates up to the plan’s number of devices, and each device holds a signed lease it verifies offline.

In the product

Customers enter a key or start a trial, and the app keeps working offline on its lease. On the web starting points, customers manage their keys and devices on a licenses page and remove a device to free its seat. In Linklet the License section is in the Mac app, which these screens do not show.

Across the API

POST /licenses/activate, /licenses/heartbeat and /licenses/deactivate take the key as their credential, POST /licenses/trial starts a trial and GET /licenses/public-key publishes the verifying key. GET /licenses lists the account’s keys and DELETE /licenses/{licenseId}/devices/{deviceId} frees a seat.

On the server

Issues a key inside the billing transaction, once per subscription. A plan change follows the plan, and a lapsed subscription expires the key at its period end. Leases are Ed25519, bound to one device and never run past the license’s expiry.

What it guarantees

• Re-activating a device never takes a second seat
• A device gets one trial per product
• Erasing an account revokes its keys

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. A lease stays valid offline until it ends, 7 days by default, so a revoked key stops a device that never checks in only then. Keys are not tamper-proof copy protection, and LICENSE_SIGNING_PRIVATE_KEY stays with the host.

Your records copied into one search index, kept current as they change and rebuilt from the source whenever needed. Each product decides which of its records are searchable.

In the product

A link a user just made or edited is findable at once. Rebuilding the index never loses a record users can see.

Across the API

GET /search/sources lists the kinds of record the index holds. POST /search/reindex rebuilds one kind of record for the caller.

On the server

Can write each record’s search entry in the same transaction as the record, so a rolled-back change leaves nothing behind. A rebuild replaces one owner’s entries for one kind at once, bounded to ten thousand.

What it guarantees

• Each owner’s entries stay theirs
• Result links stay inside your app
• The index can always be rebuilt

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Full-text search over the index, ranked so a title match comes first. Users type plain words, and nothing they type is treated as search syntax.

In the product

Users search everything they own from one box and see the best matches first, titles before descriptions and content.

Across the API

GET /search answers up to fifty records for the caller, filtered by kind when asked.

On the server

Every query names the caller’s own index and repeats that limit in every join. Queries are bounded to twelve words, two hundred characters and fifty results.

What it guarantees

• Typed text is never search syntax
• No query reaches another owner’s records
• Ties rank the same way every time

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

One list of the things users can do in your product, each one checked against the person asking. Every surface lists and runs commands the same way.

In the product

Users see only the commands they may run. A command either opens a page of your app or runs an action you wrote.

Across the API

GET /commands lists the commands the caller may run. POST /commands/{commandId} runs one, and a retry with the same idempotency key replays the first answer.

On the server

Your product authorizes every command for the current caller before it is listed or run. Actions run inside the operation’s transaction, and their errors never reach the person.

What it guarantees

• Only allowed commands are listed
• Automations never list or run commands
• A retried command runs once

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

A command palette that searches commands and the person’s own records together, forgiving typos. It works in the browser and in SwiftUI.

In the product

Users open the palette, type a few letters or a misspelling, and pick a record or a command. If record search fails, commands still work.

Across the API

GET /palette answers matching commands and records for the caller. Browsers load the shared matching from /assets/commands-palette.js.

On the server

The signed-in person is the only source of whose records are searched, and typo corrections draw only on that person’s records. Queries are bounded to eighty bytes and fifty results a group.

What it guarantees

• Exact matches come before corrections
• Corrections never reveal another person’s words
• Actions still run through commands

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Transactional email through one mailer, with a development inbox and production providers. Each send carries its idempotency key to the provider, so a retried send is recognized.

In the product

Users receive sign-in links, invitations and notices by email. In development every message lands in a local inbox instead of being sent.

Across the API

GET /dev/mail lists captured messages outside production, for the configured operator only. Other capabilities send through the mailer rather than a route of their own.

On the server

Constructs one provider at startup behind the mailer interface. Production names its provider and never permits the development inbox, and providers that carry credentials refuse unsafe endpoints and redirects.

What it guarantees

• Production never uses the development inbox
• A retried send is recognized by its key
• Provider secrets stay with the host

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Production needs your own Resend key or SMTP relay, which stays with the host.

Durable in-app notices and queued email, each checked against the person’s choices before anything is stored.

In the product

Users read notices in the app’s activity list and mark them read. A notice links only to a page inside your product.

Across the API

GET /notifications lists the caller’s notices and POST /notifications/{messageId}/read marks one read.

On the server

The message, its delivery records and its email job commit together, so nothing is queued for a message that did not save. Ending someone’s access withdraws their messages and any unsent email in the same transaction.

What it guarantees

• An idempotency key binds to one message
• Read state never crosses owners
• Email is delivered at least once

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Topics your product registers, each with in-app, email and push channels users turn on and off. A channel the topic requires stays on.

In the product

Users choose, topic by topic, whether Linklet tells them in the app, by email or by push. Security notices always arrive by email.

Across the API

GET /communication/preferences lists the caller’s topics and channels. PUT /communication/preferences/{topic}/{channel} sets one and DELETE returns it to the topic’s default.

On the server

Evaluates the registered topic for every channel before a message exists. Unknown topics and channels fail closed, and a topic the product hides still honors a channel the person turned off.

What it guarantees

• Required channels cannot be turned off
• Only the owner reads or changes their choices
• Unknown topics never default to on

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Product-owned templates for every subject, text and HTML body, with declared inputs and previews rendered from examples.

In the product

Every email and notice reads from one set of templates, so copy stays consistent across capabilities.

Across the API

GET /communication/templates lists the registered templates and GET /communication/templates/{templateId}/preview renders one from its declared examples.

On the server

Parses and sample-renders every template at startup, so broken copy stops the server rather than a send. HTML is escaped by context, and subjects refuse line breaks.

What it guarantees

• Missing or unknown variables are refused
• Previews never need customer data
• Every input and output has a size bound

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Frequent activity collected into daily or weekly summaries, closed on a schedule and mailed once.

In the product

Users choose how often digests arrive, or turn them off. Turning digests off or back on discards what was waiting, so they never get mail about activity from while digests were off.

Across the API

GET /communication/digests reads the caller’s cadence and windows, and PUT /communication/digests sets the cadence.

On the server

Rechecks the cadence and the email choice when a window closes, and commits the closed window with its delivery job. Each digest holds at most 500 items.

What it guarantees

• Each item is collected once
• A window and its delivery commit together
• Only the signed-in person reads their digests

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Push notifications to the owner’s Apple devices through APNs. Every APNs answer is classified as delivered, retry, drop the device or failed.

In the product

The app registers its device token once per installation. Users see their devices, remove one and send themselves a test.

Across the API

GET /push/devices lists devices and POST /push/devices registers one. DELETE /push/devices/{deviceId} removes a device and POST /push/devices/{deviceId}/test sends it a test.

On the server

Signs APNs provider tokens with a key that never leaves the server’s configuration. A device APNs no longer delivers to is forgotten, and a refusal that needs a change is never retried.

What it guarantees

• A device token is never returned
• A token belongs to one owner at a time
• An owner keeps at most 50 devices

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite

Push reaches an Apple app, which registers through the API server profile. A web or React product has no device to register until ADR 0064's additive clients let an Apple client sign in to it.

Known limit. Push needs an Apple app and your APNs key, which stays with the host. Without the key, pushes are recorded for development and not sent.

One routing table instead of scattered sends. Routes match events and name the channels, people and attempts, and a dry run shows what an event would send.

In the product

Your product decides which events reach users by push, email or the in-app inbox. Owners can try an event against their routes before relying on them.

Across the API

GET /routing/routes reads the table and PUT /routing/routes replaces it. POST /routing/try runs a dry run and GET /routing/deliveries lists what was sent.

On the server

Records deliveries and enqueues their jobs in one transaction. Each delivery is tried at most its route’s attempts, up to 10, and ends sent, failed, unreachable or suppressed with a reason.

What it guarantees

• A person hears once per channel per event
• Routing an event again sends nothing new
• Only the owner replaces their routes

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

A customer’s conversation with your operators, opened from the web, an app or an assistant with its owner’s key, and worked on a board of four fixed lanes your product may relabel.

In the product

Customers open a case with a subject, a topic and what happened, read the replies and answer in the same thread. When it is solved they can mark it resolved and rate it once, from 1 to 5.

Across the API

GET /cases lists the caller’s cases and POST /cases opens one. POST /cases/{caseId}/messages replies, POST /cases/{caseId}/resolve resolves it and POST /cases/{caseId}/rating rates it. Operators work the desk under /desk/cases.

On the server

Commits each change with its messages, timeline, audit receipts, events and notifications in one transaction. An assistant writes triage and reply drafts, and nothing reaches the customer unless an operator sends it. A case waiting on its customer is nudged after 5 days and resolved after 10 by default.

What it guarantees

• An internal note never reaches the customer
• Customers read and write only their own cases
• Receipts never carry a message’s words

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. The desk drafts from built-in rules that need no model. A model assistant comes with the separate cases assistant capability, runs on your own provider key within a monthly desk budget, which stays with the host, and falls back to the rules when it fails.

A bounded model assistant for your own support desk, using your provider key and a monthly desk budget.

In the product

Operators inspect private suggested triage and reply drafts before deciding what to send. Customers receive no automatic model reply.

Across the API

The desk requests private suggestions through its existing support workflow; sending remains a separately authorized operator action.

On the server

Reserves and settles actual model usage in the durable ledger, keeps suggestions private, and falls back to rules when budget is exhausted or a provider fails.

What it guarantees

• An operator reviews before sending
• Actual model usage settles durably
• An exhausted budget adds no model spend

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Bring your model-provider credentials and desk budget. Local reference checks do not qualify a live provider.

Delegated access for your support team. An operator asks to read an account for a set time, its owner approves, and every read, note and action is recorded. Support never signs in as the customer.

In the product

Customers see who from support is asking, why and for how long, then approve, deny or end the access. Linklet’s Support access, above, is one way to show it.

Across the API

Operators ask with POST /support/grants and open approved access with POST /support/grants/{grantId}/activate. Owners read requests at GET /support/access and answer with POST /support/access/{grantId}/approve, deny or revoke.

On the server

Binds each approved grant to one approval, given from a sign-in in the last 15 minutes, and fails closed on every read, note and action once access expires or ends. Resources return only their registered fields, with confidential values masked and restricted ones left out.

What it guarantees

• Only the person approves, never a key or assistant
• Operators never act as the customer
• Ended access fails closed on every read

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. The operator console at /ops/support, with break-glass access, comes with the hypermedia and React stacks. On the API and Apple stacks operators work through the support API, which offers no break-glass access.

One private store for the bytes other capabilities keep: a local folder in development and an S3-compatible bucket in production, behind the same interface.

In the product

Nothing to show on its own. Users’ files and rendered documents live here, and they reach them only through the capability that owns them.

Across the API

No routes of its own. Files and rendered documents read their bytes through their own routes, which check access first.

On the server

Writes are bounded, measured with SHA-256 and create-only, so a retry never replaces an object. Keys are validated and relative and never come from a client, and each read is bounded by the capability asking.

What it guarantees

• Private objects never get provider URLs
• An existing object is never overwritten
• Local storage is refused in production

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Production needs an HTTPS S3-compatible bucket and its access keys, which stay with the host. Readiness checks show reference names only.

Bounded uploads for an account or a team. Each file records its size, type and SHA-256, and its bytes stay in private storage.

In the product

Users add images, PDFs and plain text, then download or delete them. Linklet saves a link’s QR poster here, and saving it again returns the same file.

Across the API

POST /assets?filename= uploads raw bytes, and an optional Idempotency-Key makes a retry return the same file. GET /assets lists files, GET /assets/{assetId}/content downloads one and DELETE /assets/{assetId} removes it.

On the server

Detects each file’s type from its bytes and keeps only allowed types; SVG and HTML are refused. Content is served with nosniff and no-store, and bytes whose upload never committed are swept after 15 minutes.

What it guarantees

• A retry under the same key stores one file
• Client media types are never trusted
• Erasing an account removes its bytes

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Files are private downloads. There is no public delivery network or malware scanning.

An owner-scoped revision tree for assets: immutable versions, branches, comparison, labels, pins and explicit restore.

In the product

Users follow file history, compare versions, label a change and pin or restore a known-good revision.

Across the API

The revision API saves versions and follows their lineage; explicit compare, pin and restore operations keep the same account boundary.

On the server

Keeps immutable revision facts and private object references, and includes revision metadata in export and account erasure.

What it guarantees

• Versions preserve their lineage
• Restore is an explicit change
• Export and erasure include revision metadata

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Configure the object-storage provider and your product’s asset rules before accepting real files.

Pages users write as drafts and publish at a public address. Guards your product registers decide what may go public.

In the product

Users write a page, publish it at its own address and take it down again. In Linklet, each account has one About page, edited in the browser.

Across the API

POST /pages drafts a page and PUT /pages/{pageId} rewrites it. POST /pages/{pageId}/publish and .../unpublish change what is public, and GET /s/{slug} serves the published page.

On the server

Runs your product’s guards before publishing. A refusal carries a code and a sentence for the owner, and a guard that cannot decide refuses. Only the owner’s own session publishes, and the publish limit is counted in the same transaction.

What it guarantees

• Public output is escaped
• Unpublishing keeps the page’s history
• Each slug names one published page

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Public responses are cached for 60 seconds, so a shared cache may serve a page for up to a minute after it is unpublished.

Hostnames users register for their public content, proved by a DNS record they add, with routing and certificate readiness reported by your host or edge.

In the product

Users register a hostname, add its record and verify it. In Linklet, domains are managed through the API, and a verified domain answers only its owner’s short links.

Across the API

POST /domains registers a hostname and returns its challenge once. POST /domains/{domainId}/verify checks it, GET /domains lists registrations with their state and DELETE /domains/{domainId} removes one.

On the server

Stores each challenge only as a SHA-256 digest. Only a verified registration owns a hostname: a pending one reserves nothing and lapses after seven days, and the first to verify wins while later claims are refused without naming the owner.

What it guarantees

• Corbelo never changes DNS
• Host reports cannot establish ownership
• A custom domain never signs anyone in

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Production proves ownership with a DNS TXT record the customer adds, and routing and certificates come from your host or edge. Linklet verifies reserved .test names locally, with no DNS record. There is no re-verification yet.

Quarantine, review and appeal for content your product registers, with a publication guard that needs an approved case for the exact content.

In the product

Users see every review of their content and appeal a rejection once, and operators decide from a review desk. In Linklet, an About page with active content such as a script, or one asking visitors for a password or money, waits for a reviewer.

Across the API

POST /moderation/cases sends a resource for review, GET /moderation/cases lists the owner’s cases and POST /moderation/cases/{caseId}/appeal appeals. The desk under /moderation/desk answers only an operator’s own session.

On the server

Keeps content digests and decision evidence, never the content itself. Before publishing, the guard reads the current content again and needs an approved case with its exact digest, so an edited page needs a new approval.

What it guarantees

• Raw content never enters moderation storage
• One appeal per rejected case
• Each decision confirms the exact case

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Owners send their own content for review. Visitors cannot report a page yet, and an approved case stays approved.

Private documents your product’s registered renderers make on a durable job, downloaded until they expire and then deleted.

In the product

Users ask for a document and download it when it is ready. In Linklet, a collection’s QR codes print on one PDF, twelve to a page, that downloads for 24 hours.

Across the API

GET /artifacts/renderers lists what can be rendered and POST /artifacts asks for a document. GET /artifacts/{requestId} follows it, .../content downloads it and DELETE /artifacts/{requestId} removes it.

On the server

Runs only registered renderers with versioned parameter schemas, and its receipts keep a digest of the parameters, never the parameters or the document’s bytes. Access is checked when a document is asked for, again when it renders and at every download.

What it guarantees

• A repeated request renders once
• Downloads are uncached, sandboxed attachments
• Expired documents are never served

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

A vocabulary your product registers for its data, with an inventory of which resources hold each class. Retention, export and analytics decide from the same classes.

In the product

Users can read each kind of data the product keeps and how sensitive it is. Linklet’s handling page, above, is one way to show it.

Across the API

GET /data/classifications lists the vocabulary. GET /data/classified reads the inventory, and PUT and DELETE on /data/classified/{resourceKind}/{resourceId} classify a resource or remove its record.

On the server

Classifies a resource only when its kind’s resolver finds it among the account’s resources. A class may stay the same or become more restrictive; a downgrade needs an explicit product workflow.

What it guarantees

• The inventory never stores payloads or credentials
• Every read and write stays within one account
• Unregistered kinds are refused

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Idempotent export and erasure-plan requests, run by bounded handlers your product registers, with evidence that cannot be deleted.

In the product

Users export everything in one file and save it. The file downloads for 24 hours, then the server deletes it.

Across the API

POST /data/portability/requests starts an export or an erasure plan, GET /data/portability/requests/{requestId} follows it and .../artifact downloads the file. GET /data/portability/handlers lists what a request covers.

On the server

Runs each account’s idempotency key at most once. Handlers write private files and return references and checksums, and an erasure plan never deletes product data.

What it guarantees

• Export contents never enter request tables
• Request evidence cannot be deleted
• Erasing an account expires its exports

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Versioned retention schedules, append-only assignments and legal holds. An executor carries out enforced policies and logs what it did.

In the product

Users can read how long each kind of data stays. In Linklet, each usage note is deleted 90 days after it is recorded.

Across the API

GET /data/retention reads the register and GET /data/retention/policies the schedules. PUT /data/retention/{resourceKind}/{resourceId} assigns one, POST .../holds places a legal hold and DELETE /data/retention/holds/{holdId} releases it.

On the server

Every assignment keeps the exact policy version and digest behind its date. An enforced policy runs across every account at its own interval, and each run is logged without naming whose records it touched.

What it guarantees

• Hold evidence is never deleted
• Releasing a hold is one way
• The server refuses a policy it cannot honor

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

The developer platform over the operation registry: the whole OpenAPI document, a plan allowance and a metadata-only log for keyed calls, signed pagination cursors and a developer portal.

In the product

Users find their API address, download the spec and copy real requests for their own workspace from a request workbench.

Across the API

GET /openapi.yaml serves the document. GET /developer/operations lists what a key may call and GET /developer/requests shows recent keyed calls.

On the server

Charges every keyed call to the plan’s API allowance before reading its parameters, and logs only metadata. Cursors are signed, bound to the account and query, and expire.

What it guarantees

• Logs never keep credentials or payloads
• A rolled-back call is neither charged nor logged
• The portal lists only what a key may call

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Signing cursors needs API_CURSOR_KEY, which stays with the host.

One operation registry: each operation is declared once and served as a REST route with its contract, MCP tools, a command and a skill entry.

In the product

Scripts, assistants and the command line call the same operations the app does, under the same rules.

Across the API

Every operation appears in the OpenAPI document with typed parameters and results. Assistants reach the owner’s operations through the MCP server at /mcp.

On the server

Runs one pipeline on every surface: admission, rate limits, authorization, approval, metering and the handler, within the operation’s timeout. A declaration that breaks a rule stops startup.

What it guarantees

• Nobody receives another caller’s replayed answer
• An idempotent write runs once per key
• A fixed operation is never widened

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Keys a person owns for their scripts, with validated scopes, optional expiry, revocation and last-used tracking.

In the product

Users make a key with only the permissions a tool needs, see when each was last used and revoke it. The secret is shown once.

Across the API

GET /account/api-keys lists keys, POST /account/api-keys makes one and POST /account/api-keys/{keyId}/revoke revokes it.

On the server

Stores only a SHA-256 digest and a non-secret prefix, and authenticates with a hashed lookup that never compares plaintext. Each successful use records its time atomically.

What it guarantees

• The secret is returned exactly once
• Expired or revoked keys never authenticate
• A key acts with exactly its scopes

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Your product as the OAuth 2.1 authorization server for the assistants users connect: PKCE, consent, audience-bound tokens with rotating refresh, and revocation.

In the product

Users approve an assistant where they are signed in, see their connected apps and disconnect one. The command line signs in with a code they approve.

Across the API

/.well-known/oauth-authorization-server describes the server. GET /oauth/authorize asks for consent, POST /oauth/token issues tokens and POST /oauth/revoke ends them. GET /account/connections lists connected apps.

On the server

Accepts only public clients that prove possession with S256 PKCE. Codes and tokens are stored as digests, and a replayed code or rotated refresh token ends the whole grant.

What it guarantees

• A token works only for the resource it names
• An assistant holds only its granted scopes
• Implicit and password grants do not exist

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Views published as MCP Apps resources, with content-addressed identities, sandbox and CSP metadata, linked tools, scoped file grants and allowlisted host file inputs.

In the product

A compatible MCP Apps host renders your view beside the conversation. The local Linklet fixture can refresh the link, read click counts and display a private QR preview.

Across the API

MCP resources expose the view. Linked app-only tools use the same operation registry; short-lived file grants return only one authorized object.

On the server

Checks account ownership and scopes on each tool call and file fetch, limits host file inputs and refuses unlisted view origins. A result can keep private display metadata out of the model’s text.

What it guarantees

• Views and tools keep the same ownership and scope checks
• Private file URLs stay in result metadata
• Revoked, expired and foreign-account grants are refused

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Host domains, sandbox origins and CSP must match the host you configure. ChatGPT, Claude and MCP Inspector have no recorded live qualification. The official SDK fixture proves the protocol integration only.

Versioned event schemas written to an outbox in the same transaction as the change they record, and delivered to consumers that each declare their event types, timeout and attempts.

In the product

Events work behind the screens. Linklet records one each time a link or collection changes, and owners and their keys read their own events over the API.

Across the API

GET /events lists the caller’s events newest first, in pages of up to 100, and a key needs events:read. POST /events/replay replays a subscription from a cursor, at most 500 events a call, to a consumer that allows it.

On the server

Leases each delivery and retries with bounded backoff, then parks exhausted work as a dead letter for operators. Replay queues a finished delivery again with a fresh attempt budget and never changes the original event.

What it guarantees

• An event commits with the change it records
• Order is kept within each aggregate
• A replay cursor never crosses accounts

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

A public receiver at POST /webhooks/inbound/{source} that checks an HMAC-SHA256 signature over the exact raw body before any product code runs.

In the product

A service your users rely on can post to your product, signed with a secret they hold. Linklet’s Link sender, above, is one way to show it: a CMS adds links with a secret Linklet shows once.

Across the API

Senders sign the timestamp, the event ID and the exact body, and send Webhook-ID, Webhook-Timestamp and Webhook-Signature. The same event sent again answers 204 with Webhook-Duplicate: true, and the same ID with different bytes is a conflict.

On the server

Reserves each source and event ID with a body digest before the handler runs, and runs handlers under timeout, panic and concurrency limits. Receipts keep state, hashes and error codes, never payloads or signatures.

What it guarantees

• The raw bytes are verified before parsing
• An event ID is handled once per source
• Receipts are for operators only

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Nothing retries a failed event from your side: the sender’s next delivery of the same bytes is its retry, up to the attempt limit.

Endpoints each account registers, with HMAC-SHA256 signed deliveries, retries through background jobs and a record of every attempt.

In the product

Users add an endpoint, keep its signing secret, send a test and pause or delete it. Each endpoint shows its recent deliveries and how each one ended.

Across the API

POST /webhooks/endpoints registers an endpoint and answers its secret once, and .../rotate-secret replaces it. GET /webhooks/endpoints/{endpointId}/deliveries lists deliveries, and .../test sends a webhook.test event with no account data.

On the server

Signs the timestamp, event ID and exact body, and refuses private, loopback and reserved addresses when it dials. Production requires HTTPS, redirects are refused and response bodies are discarded.

What it guarantees

• Keys may stop delivery, never aim it
• A secret is shown once, then its fingerprint
• A canceled delivery never sends

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Production needs a 32-byte WEBHOOK_SECRET_ENCRYPTION_KEY, which stays with the host. Private addresses are allowed only in development.

A connection to one Slack channel, with its bot token sealed as a connected credential, and a bounded sender your product calls with the messages it chooses.

In the product

Account settings on Apple and in the browser let owners connect, inspect, check and revoke a Slack connection. The pictured screens show webhooks; the Slack controls are a separate Account section. An uncertain check is never automatically replayed.

Across the API

API and Apple backends expose GET, PUT and DELETE /integrations/slack, with POST /integrations/slack/test for a deliberate check. Go web and React products also have settings forms. Connecting and revoking require recent authentication.

On the server

Posts only to Slack’s fixed chat.postMessage endpoint, refuses redirects and bounds time, message and response size. A lost or unreadable answer is reported as unknown, because Slack may have accepted the message.

What it guarantees

• The bot token opens only inside the connector
• Local mode never contacts Slack
• Production refuses local mode

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Available on every declared starting point, including Apple and both API database profiles. Live mode needs a Slack app’s bot token. Local checks explicitly say that no Slack message was sent. A live Slack workspace has not been qualified by the local reference proofs.

Envelope encryption for the tokens users grant your connectors: a random key for each record seals the token, and a host-owned key seals that key.

In the product

Users see each connected service, what it may do and when its access ends, and revoke any of them. Linklet’s Link sender, listed above with Create links, is one way to show it.

Across the API

GET /connected-credentials lists connections with their scopes, status and expiry, and POST /connected-credentials/{providerId}/revoke revokes one. Neither ever decrypts a credential.

On the server

Binds each ciphertext to its owner and provider, so it cannot move between accounts. Only connector code opens a credential, and revoking one removes its ciphertext and sealed key.

What it guarantees

• Plaintext never reaches logs or screens
• Ciphertext cannot move between accounts
• Login tokens never become connections

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Production needs a 32-byte CONNECTED_CREDENTIALS_KEY, which stays with the host.

The Swift client’s baseline: the server address, a Keychain session store and the transport every feature screen calls through. Every refusal arrives as one problem document.

In the product

Users sign in once and stay signed in to that server. Each server address keeps its own session, so a build pointed at another server never shares one. Linklet on iPhone takes its address from the build, not from a settings screen.

Across the API

It adds no routes. Each request carries Authorization: Bearer with the stored token, every non-2xx answer decodes as an RFC 9457 problem document, and a write can carry an Idempotency-Key.

On the server

Your server sees one opaque bearer token and no cookies. A 401 revokes the stored session, but only the credential that request sent, so a late refusal cannot sign out a newer login.

What it guarantees

• Tokens stay in the Keychain, never in logs
• A failed Keychain read is never “signed out”
• The app switcher never pictures a secret

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite

It is the Swift client's baseline: server configuration, the Keychain session store and the transport. API profiles can add that native client explicitly. The legacy hypermedia and React backends retain their own browser baseline; native conversion for those backends is separate follow-up work.

Known limit. For the Swift app only. The web and React blueprints carry their own client baseline, and an API product ships no client.

A catalog of the settings each capability contributes, each with a stable identity and a local destination. It records where settings live and holds no values or secrets.

In the product

Users search one list for the setting they need and go straight to it. The supplied iPhone screen keeps its last answer when a refresh fails and opens only destinations the app knows. Linklet’s clients do not show the catalog; its Settings and Account pages list their own sections.

Across the API

GET /settings lists the surfaces the caller may see, and ?q= searches them as literal text. Web stacks serve the same catalog as a page.

On the server

Validates and copies every contribution before publishing one deterministic snapshot. External URLs, control characters, duplicates and oversized metadata fail closed.

What it guarantees

• Discovery never replaces authorization
• Every destination is a local path
• The catalog holds no values or secrets

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Every configurable key is registered with a type, a default, whether it can change and an explanation. Users override values for their own account, and secret material is never configuration.

In the product

Users pick a value from its labeled choices and can return it to the default. Linklet’s default link lifetime, above, is one of its keys: new links last 7, 30 or 90 days, or never expire.

Across the API

GET /config reads the caller’s values, PUT /config/{key} sets one and DELETE /config/{key} returns it to the default. Web stacks add a page at /settings/config.

On the server

Refuses unknown, malformed and immutable writes with a named code. A stored value that no longer fits reads as the default, is logged once and fails an on-demand readiness check.

What it guarantees

• Overrides never cross owners
• Answers redact every sensitive value
• Keys and assistants may read, not write

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

A fresh request ID on every response, one log line per request, and readiness checks a deploy can wait on.

In the product

Every response carries an X-Request-ID header that an operator matches to one log line. Neither the browser nor the iPhone has a screen for it.

Across the API

GET /readyz gives a deploy the status and checks, with 503 and Retry-After while a check fails. GET /ops/readiness gives an operator on the same machine the full document, with reasons, secrets and providers.

On the server

Logs the method, matched route pattern and duration, never query strings, headers, bodies or credentials. Incoming request IDs are not trusted, liveness checks no dependencies, and readiness is time-bounded.

What it guarantees

• Every response gets a fresh 128-bit ID
• Logs never keep request content
• Readiness answers within its bound

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Raw paths are logged only when development allows them, and the full readiness document answers only on loopback.

A registry of the secrets each capability needs, by reference name, owner, purpose, rotation policy and reload strategy. Values never enter it.

In the product

On web stacks, /settings/secrets lists each reference as configured, missing, expiring, invalid or unknown. Linklet runs the API profile, so neither client has a page; its references appear in the operator’s readiness document.

Across the API

GET /ops/readiness lists each reference’s name, owner, whether it is required and its state, and the on-demand check security.secret-readiness fails when a required reference is missing or invalid.

On the server

Runs at most eight checks at once, each with a time bound, and a timeout or panic reads as unknown. The host’s configuration decides presence and builds the provider clients.

What it guarantees

• Values never reach logs, views or receipts
• A stuck check reads as unknown
• Rotation stays with the host

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. It is not a secret store. Values stay in the host’s configuration, and rotation is the host’s job.

One probe for each external provider, such as mail, billing or sign-in, reporting ready, degraded, unavailable, misconfigured or unknown.

In the product

On web stacks, operators see every provider’s state at /settings/providers. Linklet has no page for it on either client; providers appear in the operator’s readiness document.

Across the API

GET /ops/readiness lists each provider with its owner, state and reason, and any provider that is not ready marks the whole document degraded.

On the server

Probes share eight slots, honor the request’s deadline and contain panics, and their reasons are sanitized. Registration is deterministic and refuses duplicates.

What it guarantees

• Credentials appear only by name
• Each provider has exactly one probe
• Quota data never grants access

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. API stacks and Apple’s server have no page; providers report through the readiness document. Probes never inject secrets.

A durable queue in your database. Workers claim jobs under a lease, retry failures across a bounded window and set aside work that cannot succeed as dead letters.

In the product

Users never manage jobs; jobs carry the work they start. In Linklet, the weekly link report and every automation run go through them.

Across the API

GET /jobs lists the newest 100 jobs, by status and queue, for verified operators named in OPERATOR_EMAILS. It never shows a job’s payload or idempotency key, and a key, an assistant or a flow is refused.

On the server

A product inserts its change and the job it causes in one transaction. A claim counts one attempt, retries spread across an hour by default, and a permanent failure or an unknown kind goes to the dead letters.

What it guarantees

• Only the lease holder settles a job
• An idempotency key keeps one job per queue
• Erasing an account deletes its jobs

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Jobs have no page on any stack; operators read them only through the API.

One-time, interval and weekly schedules for targets your product registers. Each occurrence enqueues one background job.

In the product

Owners pick what to run, the days and a local time in their own time zone, and see the next run in their device’s time zone. They stop a schedule or delete it.

Across the API

GET /schedules/targets lists what can be scheduled and POST /schedules makes a schedule. POST /schedules/{scheduleId}/disable and .../enable stop and resume it, and DELETE /schedules/{scheduleId} removes it for good.

On the server

Advances each occurrence and enqueues its job in one transaction. After downtime a repeating schedule runs once and moves to its next future time. Each owner keeps at most 50 schedules enabled, and an interval is at least five minutes.

What it guarantees

• Clients never choose a job kind or payload
• A repeated local time runs once
• Deleting leaves an enqueued run to finish

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. No monthly or other calendar rules, and no host cron. Time zones come from the host’s zone database, or the copy built into the server when the host has none.

Owner approvals of exact operation calls. When a key, an assistant or a flow calls a guarded operation, the call waits, and the owner reads the operation’s own preview before deciding.

In the product

Owners read what waits, who asked and the preview, then approve or deny, and a signing key on their device can sign each answer. Linklet’s Waiting for you section, above, is one way to show it.

Across the API

GET /approvals lists what waits and GET /approvals/{approvalId} reads one. Only a person’s own session answers, through POST /approvals/{approvalId}/challenge and .../decision. A call that waits answers 202 with its approval ID.

On the server

Seals the preview with the approval and records it by digest; no push or mail carries it. An approval waits between five minutes and seven days, a long wait reminds once when a quarter of it remains, and its state only moves forward.

What it guarantees

• One approval allows one execution
• A changed call needs a new approval
• Decisions cannot be edited or deleted

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

An owner’s flows as versioned data: a trigger and up to 24 steps of actions, conditions, delays, waits and branches, published against your product’s operations and run through background jobs.

In the product

Owners start from a template, publish a version, turn it on and run it, then read each step’s status and attempts. Publishing and turning a flow on are separate decisions.

Across the API

GET /flows/catalog lists the templates and POST /flows saves a draft from one. POST /flows/{flowId}/publish and .../enable wait for the owner’s approval when a key or an assistant calls them, POST /flows/{flowId}/runs starts a run and GET /runs follows them.

On the server

Checks each version before it publishes and runs each step as a job. A delay or wait lasts at most 30 days and holds no lease, and a finished run is deleted 30 days after it ends.

What it guarantees

• A run starts once per trigger key
• Runs and steps only move forward
• Audit receipts hold digests, never parameters

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. It requires domain events and feature access by plan beside jobs, schedules and approvals.

Generation through one interface for OpenAI, Anthropic, Gemini, OpenAI-compatible APIs and a deterministic local provider. The host constructs one provider at startup and owns its credentials.

In the product

Users can see which provider and model answer before they ask. Linklet names them beside its Describe check and in the app’s AI settings, which is one way to show it.

Across the API

GET /ai/provider describes the configured provider and model to a signed-in caller without calling it. Other capabilities generate through the provider rather than a route of their own.

On the server

Validates and bounds every request, tool schema, response and stream. External endpoints must use HTTPS, redirects are not followed, provider failures are sanitized, and no adapter retries a billable request on its own.

What it guarantees

• Requests never carry credential material
• Production refuses the local provider
• Readiness never spends tokens

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. A real model needs AI_MODEL and its provider’s key: OPENAI_API_KEY, ANTHROPIC_API_KEY, GEMINI_API_KEY, or AI_API_KEY with AI_BASE_URL for a compatible API. Keys stay with the host. Remote providers are not yet sent a response schema, so the caller checks every answer.

Pinned prompt versions and product-owned tools a model runs through, inside a hard monthly token budget. Each generation costs one AI step, and a tool that needs approval waits for the owner’s yes.

In the product

Users see each AI request made on their device with its model and tokens, and anything waiting for their yes. Linklet’s Describe, which suggests a name and tags for a link, is one way to ask.

Across the API

POST /ai/generate runs a registered prompt version as the caller, within the caller’s budget. A call names its version, and a missing version is refused, never replaced by another.

On the server

Reserves one AI step and the most tokens a call can use before the model is asked, then settles to what the provider reports. All calls in one model response are checked before any runs, and an answer must meet its prompt’s output schema after at most one repair.

What it guarantees

• An unlimited AI allowance is refused
• Approval-required tools never run from model output alone
• Evidence holds digests, never the input or answer

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. A model is never offered a destructive operation: ai.generate refuses a destructive tool in a prompt’s list.

Versioned suites of cases and assertions, scored by deterministic checks, with each run compared against the one before. A changed suite starts a fresh comparison.

In the product

Users start a run and read its score, each case’s checks and answer, and how it compares with the last run. Linklet’s Describe check, above, is one way to show it.

Across the API

GET /ai/evaluations/suites lists suites, and GET /ai/evaluations/runs and GET /ai/evaluations/runs/{runId} read the history. POST /ai/evaluations/runs starts a run and needs an Idempotency-Key.

On the server

Bounds each run’s cases, concurrency, time per case, output tokens and kept evidence. A run is compared only with the owner’s previous run of the same suite, version and digest, and fails on a score loss beyond tolerance or a case that passed before.

What it guarantees

• Reading results never calls a model
• A retried key answers the recorded run
• The newest 10 runs of each suite are kept

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Scorers are deterministic: exact text, contained text, valid JSON, non-empty text and named tool calls. Grading with another model needs a separate capability, and this one does not meter what a run spends.

Bounded metrics with W3C trace propagation and export, an availability objective with burn rates, team incidents with an append-only timeline, and a public status page.

In the product

Team owners and admins are alerted when an incident opens and each time its state changes, on the channels they chose for incident alerts. Anyone can read a team’s public status without an account.

Across the API

GET and POST /teams/{teamId}/incidents list and open incidents, and POST /teams/{teamId}/incidents/{incidentId}/transition moves one. GET /status/{teamSlug} is the public status, and GET /ops/reliability gives the host its operator snapshot.

On the server

Measures HTTP availability against 99.90 percent over 5-minute, 1-hour and 30-day windows, and reads too little traffic as unknown. Only a team’s owners and admins change its incidents, and every change appends to the timeline in the same transaction. Metric labels come from fixed lists, and the total number of series is capped.

What it guarantees

• Resolved incidents never reopen
• The status page shows only published incidents
• An exporter never holds up a request

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. On the API and Apple stacks there is no incident page and the public status is JSON; the status page and reliability settings come with the web stacks. Exporting to an OTLP collector can use OTEL_EXPORTER_OTLP_TOKEN, which stays with the host.

Checks and actions your product registers, each with its own authorization, timeout and concurrency limit, run under idempotent receipts that keep safe evidence.

In the product

Users run a check, or an action that changes something once they confirm it, and read how each run ended. Linklet’s Library Health, above, is one way to show it.

Across the API

GET /operations/runs lists the newest runs, at most 100, for a caller holding operations:read. Linklet lists and runs its own targets through its /security/operations routes.

On the server

Runs only targets the product registered, and an action needs its exact target ID as confirmation. One tenant and idempotency key make one receipt, and a finished operation never runs twice.

What it guarantees

• Request data never reaches commands or credentials
• Receipts keep the target’s version and digest
• A failed run shows product copy, never the cause

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. It is not a deployment tool, a shell runner or a replacement for the host’s observability.

A versioned tracking plan, append-only consent receipts and a local event ledger. Events carry only classified values, and every one expires.

In the product

Users turn usage sharing on or off and see how many events are recorded. Linklet adds Delete Recorded Usage, which clears them all at once.

Across the API

GET /analytics reads the snapshot, POST /analytics/consents records a choice and POST /analytics/events records an event. DELETE /analytics/events/expired removes the owner’s expired events.

On the server

Refuses an event for a non-essential purpose without a current, granted consent receipt, and accepts only classified enum, identifier, integer and boolean values. An hourly purge removes expired events.

What it guarantees

• Only the person’s own session records consent
• Freeform text, URLs and emails are refused
• Each event keeps its tracking plan’s digest

Supported starting points

• SwiftUI + Go + SQLite
• SwiftUI + Go + PostgreSQL
• Go API + PostgreSQL
• Go API + SQLite
• Go + HTMX + PostgreSQL
• Go + HTMX + SQLite
• React + Go + PostgreSQL

Known limit. Cookieless collection, sessions, funnels and rollups are out of scope. Events stay in your database; sending them to a provider is a host job that reads the ledger.