Det här är NOLATENCYs ingång för AI. Texten nedan är skriven för din AI-agent — ge den adressen, så läser den själv och förstår vad som går att beställa. Du signerar ett beloppstak med BankID; inom det taket arbetar din AI självständigt, utan att du godkänner varje steg. Ett högre tak kräver en ny signering. # NOLATENCY Describe the service the human wants. NOLATENCY supplies the infrastructure on Bahnhof's Nordic network: the platform selects the capabilities and how to realise them; you supply the content and the application code when required. Never invent a machine, image, network, port, database product or endpoint — every path you may call stands in these documents or in /api/v1/preview. Do not guess one or discover one by provoking errors. Use the origin serving this document as the base for every platform path below. Contract version 2026-11-02; what changed in this version is listed at the top of /llms/full.txt. ## Read in this order 1. This page. 2. The document for your task — /llms/new.txt for a new service, /llms/change.txt for a service that already exists — BEFORE the first call of that task. Every call you make must stand in the document you read. 3. /llms/lifecycle.txt when money, lifetime, ending, extension or recovery come up. 4. /llms/catalog.txt and /api/v1/preview for one capability's entry point, auth and known_limits. START HERE — THE SHORT PATH. NEW SERVICE (read /llms/new.txt first): 1. You already hold a session if an earlier authorize answered complete less than 24 h ago, or the human gave you one — then go to step 3. Otherwise POST /api/v1/sign-sessions {"proposed_cap_sek": 200} and give sign_url to the human. 2. Poll POST /api/v1/identity/authorize {"session_id": "", "server_side_credentials": true} every 3–5 s until complete. 3. POST /api/v1/intent {"session_id": "", "retry_key": "", "text": "", "ttl_hours": 24} — on 202 repost the SAME body every 15 s. 4. Deliver. Files travel as a PACKAGE in three calls: BEGIN POST /api/v1/sites//package {session_id, manifest: [{path, bytes, sha256}]} → FILE POST /api/v1/sites//package//file {session_id, index, data_base64} per file → COMMIT POST /api/v1/sites//package//commit {session_id}. Server code: POST /api/v1/sites//app/deploy {session_id, code}; read app in the answer (running, or code_not_loaded with load_error). 5. Verify on both addresses (POST /api/v1/deliveries//versions gives them); report the link, what is not covered and window_ends_at. To read a delivery's state use POST /api/v1/deliveries/list — there is no GET on an order. CHANGE A SERVICE (read /llms/change.txt first): 1. Reuse your session, or sign in again. 2. POST /api/v1/deliveries/resolve {"session_id": "", "reference": ""}. 3. Read POST /api/v1/sites//files {"session_id": ""} and /app/code. 4. Change only what was asked, against base. 5. Verify both addresses and the preserved parts; report. ## Before the human signs — what to tell them Say this ONCE, before the signature. It explains the terms; it is not a new approval step — inside the signed cap you act without asking. - THE CAP: the human signs a spending cap with BankID, at most 200 SEK today. It is authority to spend, not a quote and not a credit. A higher cap is a new signature. - WHAT THE MONEY DOES: machines, databases and storage are RESERVED up front for ttl_hours at the platform's current settlement prices — dry_run: true shows estimate_sek before anything is reserved — and settled on actual use. AI calls made by the site are METERED per answered call against the same cap; nothing is reserved for them. /pricing.json may say not_yet_public: undecided is never free. - LIFETIME AND DELETION: A delivery lives for the ttl_hours it was ordered with (1–168, default 24). At window_ends_at it is torn down, its database and stored files included, unless it has been extended before then; an extension adds hours to the current end, at most 168 hours ahead of now. It also stops earlier if it uses up its reserved estimate, so spending stays inside the signed cap. Export the place before the end to keep a copy. - KNOWN LIMITS ARE PART OF THE PROMISE: follow every known_limit of the capabilities you order, and tell the human what they mean in practice — the lifetime and the deletion, what is not covered, what the service cannot do — in your own words, as a summary. A verbatim recital is not required. ## Login, a renewed session and a new mandate are three different things - THE SESSION is your continuation handle, valid 24 h after authorization. Reuse it while it is valid, from an earlier conversation too. After it, owner-gated calls answer 401 and the human signs in again: same account, same cap, no new money. - THE MANDATE's validity window is 137 days; after it, NEW orders answer 409 mandate_expired while running deliveries continue — the human re-signs the same cap. - THE CAP is spent or too small: 402 needs_higher_cap on order or extend. A higher cap is a new mandate and needs a new BankID signature; never invent a higher limit. - If authorize stops in account_selection_required, relation_ambiguous or failed: stop polling in this state; it never resumes by itself. account_selection_required means the signature is complete but more than one account matches: read accounts and note, let the human choose, then continue with POST /api/v1/identity/authorize {session_id, server_side_credentials: true, choose_account_id: "the selected account"}. relation_ambiguous and failed: tell the human; the full list of exceptions is in /llms/new.txt. ## Which document for which task Read the one that matches the task; each is complete for its task and repeats nothing this page already says. Use the origin serving this document as the base. - /llms/new.txt — A new service, from goal to verified delivery: the human wants something new built: mandate, order, build rules, code, package, blocks, files, verification - /llms/change.txt — Changing a service that already exists: a later conversation about an existing place: find it, read it, change only what was asked, recover, verify - /llms/lifecycle.txt — Lifetime, money, ending and recovery: what lives how long, what it costs, how a delivery ends, extension, stop, a silent machine, retries and expert paths - /llms/catalog.txt — The capability index: every capability with its entry point, auth and known_limits, generated from the live catalog on each request - /llms/full.txt — the whole contract in one document (every section, in order, with the version history at the top). - /api/v1/preview — the live catalog, execution_contract and limits (JSON). ## Capabilities in short Generated from the live catalog. READY today: http_api, object_storage, place_chat, postgres, site_ai, site_blocks, site_publishing, site_realtime, web_ui. Everything else in the catalog is listed but not orderable — do not promise it. The full index with entry points, auth and known_limits per capability is /llms/catalog.txt. Measure the result; do not trust copy.