* feat(sandbox,branding): prod-parity demo with AI gating + accounted rebrand Sandbox now ships with seeded suppliers, supplier invoices, an asset, a verified agent_profile, and pending operations so the demo company exercises every prod surface. Server-side `guardSandbox()` short- circuits any AI or paid-external API call (Bedrock chat/composer, Resend invoice send, Riksbanken FX, VIES, etc.) and the AgentSheet swaps in a SandboxAgentPreview that explains what's gated and offers a register CTA. DashboardContent no longer mounts the NewUserChecklist when the agent is already built, fixing the path that let sandbox users still trigger /onboarding/agent. Visible branding flips from Gnubok to Accounted: new BrandWordmark component (Hedvig Letters Serif 700), new app/icon.png + PWA icons generated from the accounted icon, default appName updated. URLs, header names, API key prefixes, hostnames, and event/cookie/ localStorage keys keep `gnubok` — the rebrand is visual only. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(sandbox): hardcode supplier-invoice arrival numbers in seed get_next_arrival_number is MAX(arrival_number) + 1 against the same table we're about to insert into. Calling it twice before either row lands made both calls return 1, which then violated the (company_id, arrival_number) unique index — POST /api/sandbox/seed 500'd on first sandbox start. The seeded company is brand new in this branch so 1 and 2 are guaranteed unused; hardcoding side-steps the race entirely. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(sandbox): set paid_amount=0 on unpaid supplier invoice PostgREST normalizes the column set across rows in a bulk insert, so the second supplier invoice (Espresso House, status=registered) was being sent with paid_amount=null because the first row (Telia, paid) set it. supplier_invoices.paid_amount is NOT NULL DEFAULT 0; the default only kicks in when the column is *absent* from the payload, not when it's explicitly null. Set it inline to side-step the normalization. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(sandbox): set actor_type=agent_chat on seeded pending_operations pending_operations only allows user-scoped INSERTs via the `pending_operations_chat_insert` policy, which requires actor_type='agent_chat' alongside auth.uid()=user_id + company membership. The seed was inserting with the default actor_type='user', tripping the RLS check. Also lift risk_level from preview_data (where it was unused) onto the row itself, matching the column added in 20260430120000_pending_operations_actor_and_risk. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(pr-review): address PR #585 review feedback Fixes called out by the core-only CI check, Greptile, and the compliance + Swedish-accounting bots: - AGI Programnamn pinned back to 'gnubok' (CI blocker). The XML Skatteverket receives must keep the stable software identifier regardless of the visual rebrand — same rule as the v1 health endpoint's `service: 'gnubok'` literal. - handleCreateAccount in SandboxAgentPreview + ChatEmptyState now wraps signOut() in try/catch so a transient Supabase failure doesn't strand the user on a dead button (greptile P2 × 2). - /api/currency/rate hard-fails on missing companyId instead of conditionally skipping the sandbox guard (greptile P2 / compliance V8.2.1). - topUpSandboxAdditions now delegates to ensureSandboxAgentProfile; the assistant persona lives in exactly one place across the seed, layout backfills, and top-up path (greptile P2 outside-diff / compliance SOC2 CC6.1). - ensureSandboxAgentProfile drops the userId param and sets verified_by_user_id to NULL — synthetic seed data should not attribute verification to a real user (compliance V8.2.1 / GDPR Art. 25(2)). Errors now logged via the structured logger instead of being silently swallowed (V16). - Sandbox seed swaps real-world company names (Telia, Espresso House) for clearly-synthetic Demo-prefixed brands using the 5559... documentation org-number range (compliance A.8.33). Asset cost bumped 24 000 → 35 000 SEK so the demo clears the förbrukningsinventarier threshold and illustrates capitalization unambiguously (swedish-asset-accounting). - Representation pending-operation preview corrected: VAT label fixed from 6% → 12%, and input VAT split between the avdragsgill (2641) and ej-avdragsgill (5811) portions to match swedish-vat / ML 8 kap rules (swedish-vat). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(pr-review): seed preview consistency + AGI Programnamn constant Two last review-bot items before merge: - Sandbox seed: the representation pending-operation preview was splitting the 240 SEK café meal 60/180 between 5810 and 5811, which is wrong for a single attendee under the 300 SEK / person avdragsgill cap (ML 8 kap) — the entire amount is fully avdragsgill in that case. Collapse the preview to a single 5810 + 2641 + 2440 entry so it matches the supplier_invoice_items row 1:1 and stops teaching demo users an incorrect bookkeeping pattern. - Hoist the AGI Programnamn 'gnubok' literal into a named constant with a comment pointing to potential future Skatteverket vendor registration (per the swedish-compliance bot's nit). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(sandbox): avoid BFL duplicate-verification on pending op + fix VAT cap comment Swedish-compliance bot caught two final nits: - The pending operation for the Demokafé representation was using the same supplier_invoice_number as the already-seeded supplier_invoices row (88245). If the sandbox user approved the staged operation, the insert would have created (or attempted) a duplicate verification — BFL 5 kap. requires each affärshändelse be recorded exactly once. Swap the staged operation's invoice number to a distinct value (INKOMMANDE-2026-001) so approval cleanly creates a new row. - The preview comment described the 300 SEK threshold as an "avdragsgill cap". The actual rule (ML 8 kap. 9 §) caps the deductible VAT at 25 % × 300 SEK × antal_personer = 75 SEK per person — the 300 SEK is the tax base, not the total. Math here is correct either way, but the comment now states the correct formula so future seed edits don't propagate the wrong understanding. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
110 lines
5.2 KiB
TypeScript
110 lines
5.2 KiB
TypeScript
import { API_V1_VERSION } from '@/lib/api/v1/version'
|
|
|
|
export const LANDING_MD = `# accounted API
|
|
|
|
> Swedish double-entry bookkeeping as a public REST API for agents and integrations. API version \`${API_V1_VERSION}\`.
|
|
|
|
The accounted API lets you do anything the dashboard can do — create invoices, ingest bank transactions, file VAT declarations, run payroll, and subscribe to webhooks for state changes. Every endpoint is designed for autonomous agents first: machine-readable schemas, dry-run previews, idempotent retries, and inline audit blocks on every write.
|
|
|
|
If you've used [Stripe's API](https://docs.stripe.com/api), the shape will feel familiar — bearer-token auth, dated API versions, webhook signature verification, idempotency keys. The accounting concepts are Swedish (BAS chart, BFL retention, K2/K3, momsdeklaration) but the surface is built for the same kind of integrator.
|
|
|
|
## Authentication
|
|
|
|
All requests authenticate with a bearer token in the \`Authorization\` header:
|
|
|
|
\`\`\`bash
|
|
curl https://gnubok.app/api/v1/companies \\
|
|
-H "Authorization: Bearer gnubok_sk_live_..."
|
|
\`\`\`
|
|
|
|
Create keys in the accounted dashboard at **/settings/api**. Two key prefixes are available:
|
|
|
|
- \`gnubok_sk_live_*\` — hits real customer data. Use in production.
|
|
- \`gnubok_sk_test_*\` — bound to deterministic sandbox companies. Safe for evals, demos, and agent learning. Same surface, different blast radius.
|
|
|
|
Each key carries one or more **scopes** (\`invoices:read\`, \`invoices:write\`, \`payroll:write\`, \`webhooks:manage\`, ...) that gate which endpoints it can call. Scopes are listed on every endpoint reference page.
|
|
|
|
Rate limit: 100 requests per minute per key, returned in \`X-RateLimit-*\` headers.
|
|
|
|
## Base URL
|
|
|
|
\`\`\`
|
|
https://gnubok.app/api/v1
|
|
\`\`\`
|
|
|
|
URLs include the company id explicitly:
|
|
|
|
\`\`\`
|
|
GET /api/v1/companies/{companyId}/invoices
|
|
POST /api/v1/companies/{companyId}/invoices
|
|
\`\`\`
|
|
|
|
A multi-company key can act on any company the underlying user is a member of — the URL is the source of truth, not a default. List the companies a key can access with:
|
|
|
|
\`\`\`bash
|
|
curl https://gnubok.app/api/v1/companies \\
|
|
-H "Authorization: Bearer gnubok_sk_live_..."
|
|
\`\`\`
|
|
|
|
## Core principles
|
|
|
|
These four invariants hold across the entire surface — once you've internalised them you can predict the shape of any endpoint without reading the reference.
|
|
|
|
**Dry-run on every write.** Append \`?dry_run=true\` (or send \`X-Dry-Run: true\`) to any POST/PATCH/DELETE to preview the effect — the response shows the journal lines, voucher number, account deltas, and any validation errors that would surface, but commits nothing. Use this in agent test-loops to validate inputs before paying the side-effect cost.
|
|
|
|
**Idempotency-Key on every write.** Pass a UUID in the \`Idempotency-Key\` header. Replays of the same key+body return the original response with \`Idempotent-Replayed: true\` (24h cache). Replays with a different body return \`409 IDEMPOTENCY_KEY_REUSE\`.
|
|
|
|
**Strict-mode write semantics.** A v1 mutation either commits fully or returns a structured error code with no side effects. The dashboard soft-fails on partial writes (a human is there to retry); the v1 surface aborts. This means you never see "the invoice was sent but the email failed" — either both happened or neither did.
|
|
|
|
**Inline audit on every write.** Every successful write response includes an \`audit\` block in \`meta\` with the voucher number, audit-trail URL, and immutability timestamp. No second round-trip needed to confirm what happened.
|
|
|
|
## Response envelope
|
|
|
|
Every response has the same shape:
|
|
|
|
\`\`\`json
|
|
{
|
|
"data": { ... },
|
|
"meta": {
|
|
"request_id": "req_...",
|
|
"api_version": "${API_V1_VERSION}",
|
|
"next_cursor": "...",
|
|
"audit": { "voucher_number": "A-2026-042", "voucher_url": "..." }
|
|
}
|
|
}
|
|
\`\`\`
|
|
|
|
Errors swap \`data\` for \`error\`:
|
|
|
|
\`\`\`json
|
|
{
|
|
"error": {
|
|
"code": "PERIOD_LOCKED",
|
|
"message": "Den valda perioden är låst.",
|
|
"message_en": "The selected period is locked.",
|
|
"remediation": { "description": "Unlock via /fiscal-periods/{id}/unlock or pick an open period.", "tool": "fiscal_periods.unlock" },
|
|
"details": { "fiscal_period_id": "..." },
|
|
"docs_url": "https://gnubok.app/docs/api/errors#period_locked"
|
|
},
|
|
"meta": { "request_id": "req_...", "api_version": "${API_V1_VERSION}" }
|
|
}
|
|
\`\`\`
|
|
|
|
Every error code is documented in the [error reference](/docs/api/errors).
|
|
|
|
## Where to go next
|
|
|
|
- **[Quickstart cookbook](/docs/api/cookbook/quickstart)** — send your first invoice in five minutes.
|
|
- **[API reference](/docs/api/reference)** — every endpoint, grouped by resource.
|
|
- **[Webhooks](/docs/api/webhooks)** — subscribe to events with HMAC-signed delivery.
|
|
- **[Errors](/docs/api/errors)** — every stable error code with remediation.
|
|
- **[Versioning](/docs/api/versioning)** — how API versions are pinned and upgraded.
|
|
- **[Changelog](/docs/api/changelog)** — what shipped when.
|
|
|
|
For LLM-based agents:
|
|
- **[\`/llms.txt\`](/llms.txt)** — concise agent-discovery index.
|
|
- **[\`/llms-full.txt\`](/llms-full.txt)** — full docs concatenated for ingestion.
|
|
- **[\`/api/v1/openapi.json\`](/api/v1/openapi.json)** — machine-readable OpenAPI 3.1 spec.
|
|
- **[\`/.well-known/skills/index.json\`](/.well-known/skills/index.json)** — accounted-specific skill catalogue.
|
|
`
|