Standard Apps

Standard apps are apps the platform ships whole. Where a custom app is something you author — rules, bindings, output contract, versions — a standard app arrives finished: its screens, its logic, and its vocabulary are part of the platform, and adding one to a workspace makes it live there at once, with nothing to write or publish. Each standard app still is an ordinary app row in your workspace, so it appears in the gallery, can be pinned to the sidebar, and is addressed by the same /v1/apps surface as every other app.

You add one from the Create an App wizard: choose Add a standard app, and the wizard lists the catalog as tiles, each with its icon and a sentence on what it does. Tiles for apps the workspace already holds are marked Added; on the others, choose Add and the app is created with a fixed slug and opens on its own dedicated page. The slug is the contract between the app row and that page, which is why it is fixed by the platform rather than derived from the name. Adding a standard app requires the configure tier — a workspace owner in the web app.

In the gallery, a standard app carries a Standard app chip instead of a mode chip and always counts as live. It has no versions, so its card shows when it last ran, or when it was added if it never ran. Everything else behaves like any app: owners can pin it to the sidebar rail, and the card menu's Rename sets a workspace-specific name, icon, and one-sentence description. Two workspaces running the same standard app can therefore call it different things, while its slug — and the routes and tools derived from it — stays the same everywhere.

What the catalog includes

Document Generation is a platform-standard app: it is present in every workspace from the start, so it is always on the gallery and never needs to be added. It turns your own Word templates into finished letters and agreements, one per record of a data product, with every value traceable to where it came from. See Document Generation for the full walkthrough.

Other standard apps are added from the wizard when a workspace wants them. Contracts keeps every contract with its amendments, renewals, and terminations folded into the terms in force, its status, and the dates that need someone — each term cited to its source line. Money Found surfaces recoverable money in the documents and tables the workspace already holds, every row cited to its source line. The wizard always shows the current list; the catalog can include further apps built for specific workflows, and each describes itself in the wizard before you add it.

Under the hood a standard app is deliberately plain. It is created with a fixed slug, a display name, and a mode, and carries no authored logic of its own — no rule cards to compile, no draft to publish, no acceptance set to maintain. Its dedicated page does the work, reading the workspace's data products and documents through the same access checks as every other screen. Because the app row is ordinary, GET /v1/apps lists it next to your custom apps with its slug, its workspace-specific name and icon, and its pin state, so scripts and agents can find it the same way they find anything else.

Who can do what follows the same role ladder as the rest of Apps. Anyone in the workspace can open a standard app the gallery shows them, and what they see inside it is bounded by their Sources access. Adding a standard app, pinning it to the sidebar, and renaming it are owner actions, because they change what the whole workspace sees. Work inside each app follows its own page's permissions — in Document Generation, for example, uploading templates, confirming field sheets, and generating need the member role, while viewers can read templates and history.

Choose a standard app when your need matches what it already does — you get a finished surface on day one and future improvements as the platform ships them. Build your own app when the decision is specific to your business: your rules in your words, your data products as inputs, your output contract, your thresholds, and a versioned ledger you can replay and diff before every change. The two coexist in one gallery, and a workspace commonly runs both.

# Every app row in the workspace, standard apps included
curl -s https://api.talonic.com/v1/apps \
  -H "Authorization: Bearer tlnc_your_api_key" \
  | jq '.apps[] | { slug, display_name, mode, nav_pinned }'

# → { "slug": "doc-gen", "display_name": "Document Generation", "mode": "assisted", "nav_pinned": false }
#   (display_name is this workspace's own — a rename shows here; the slug never changes)

curl -s -X PATCH https://api.talonic.com/v1/apps/$APP_ID/presentation \
  -H "Authorization: Bearer $OWNER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"display_name": "Letters", "description": "Renewal and notice letters from our contract records."}'
# → { "display_name": "Letters", "display_icon": null,
#     "description": "Renewal and notice letters from our contract records." }