---
title: "Canonical agent workflows manifest"
method: GET
path: "/workflows.json"
tags: ["Discovery"]
---

# Canonical agent workflows manifest

`GET /workflows.json`

## Request

- Base URL: `https://www.apier.no`
- URL: `https://www.apier.no/workflows.json`
- Auth: none required

Zero-auth JSON manifest of common multi-step workflows an agent might want to run. Each workflow references capability ids from /api/v1/capabilities so the published contract stays internally consistent — an agent framework can chain `capability_id` → OpenAPI `operationId` → HTTP shape in two lookups. Workflow `id` values and `steps[].capability_id` values are APPEND-ONLY forever; new workflows may be added, existing ones gain new optional fields but never shrink or rename. `schema_version` on both the top level and `_meta` advertises the manifest schema for client caching.

Each workflow carries enriched planner metadata — `intent`, `expected_outcome`, `failure_modes`, `estimated_time_ms`, and `agent_instructions` — plus per-step `expected_response` describing the body the step returns on success. The response also includes a schema.org JSON-LD `@context` and `@graph` with one `HowTo` node per workflow, so AI crawlers that speak schema.org but not Apier's bespoke shape can still plan a multi-step flow. See /recipes for the human-readable counterpart.

## Response `200`

Workflow manifest with `_meta` carrying data_freshness and workflow_count, plus a schema.org JSON-LD `@graph` of HowTo nodes.

- object
  - `version` string, required
  - `schema_version` string, required
  - `@context` string, required: schema.org JSON-LD context URL. Always `https://schema.org` — present so crawlers can interpret the `@graph` array as schema.org `HowTo` nodes.
  - `@graph` object[], required: schema.org JSON-LD projection — one `HowTo` node per workflow, derived from the same data as `workflows`. Intended for AI crawlers that consume schema.org but don't speak the Apier-native workflow shape.
    - `@type` 'HowTo', required: schema.org node type for each projected workflow. Always `HowTo`.
    - `@id` string, uri, required: Canonical stable identifier for this workflow node. Format is `<origin>/workflows.json#<workflow.id>` where `<origin>` is derived from the deployment's NEXT_PUBLIC_APP_URL (scheme + host + port).
    - `name` string, required: English workflow title mirrored from `workflows[].name_en`.
    - `description` string, required: English workflow summary mirrored from `workflows[].description_en`.
    - `totalTime` string, required: ISO 8601 duration approximating end-to-end workflow time, derived from `estimated_time_ms` (rounded up to the nearest whole second, minimum PT1S). Agent planners use this to decide synchronous vs queued execution.
    - `step` object[], required: Ordered schema.org HowToStep nodes mirroring `workflows[].steps`.
      - `@type` 'HowToStep', required: schema.org node type for each step. Always `HowToStep`.
      - `position` integer, required: 1-based step order, mirroring `workflows[].steps[].step`.
      - `name` string, required: Step purpose mirrored from `workflows[].steps[].purpose` — why this capability call exists in the workflow.
      - `text` string, required: Expected successful response summary mirrored from `workflows[].steps[].expected_response`.
  - `workflows` object[], required
    - `id` string, required
    - `name_en` string, required
    - `name_nb` string, required
    - `description_en` string, required
    - `trigger_intent_en` string, required
    - `intent` string, required: Natural-language description of what the workflow achieves — the goal, not the mechanics.
    - `expected_outcome` string, required: What the agent holds in its context after the workflow completes successfully.
    - `failure_modes` string[], required: Known failure-mode identifiers agents should plan for. Append-only per workflow.
    - `estimated_time_ms` integer, required: Rough total time for all steps end-to-end, in milliseconds. Intended for agent planners deciding whether to run a workflow synchronously or queue it.
    - `agent_instructions` string, required: Step-by-step instructions an agent can paste verbatim into a system prompt or tool-use plan. Plain text with numbered steps; uses placeholders like `<ORG_NUMBER>`, `<CURRENCY>`.
    - `steps` object[], required
      - `step` integer, required: 1-based position of this step within the workflow. Strictly ascending across `steps[]`.
      - `capability_id` string, required: Matches a capability id in /api/v1/capabilities. Lets an agent chain workflow step → capability → OpenAPI `operationId` → HTTP shape in two lookups.
      - `purpose` string, required: Why this capability call exists in the workflow, expressed in agent-planning terms (e.g. 'Call GET /api/v1/...'). Human-readable but short enough to paste into a tool-use plan.
      - `expected_response` string, required: One-sentence description of the response body an agent should expect when this step succeeds.
    - `requires_auth` boolean, required
    - `tier_minimum` 'free' | 'starter' | 'professional' | 'enterprise', nullable, required
  - `_meta` object, required
    - `data_freshness` string, date-time, required
    - `source` string, required
    - `schema_version` string, required
    - `workflow_count` integer, required

---

[API](https://skmtc.dev/apier/apis/apier-no-api.md) · [All operations](https://skmtc.dev/apier/apis/apier-no-api/llms.txt) · [OpenAPI document](https://skmtc.dev/apier/apis/apier-no-api/revisions/9ec19bc87311?raw)