> ## Documentation Index > Fetch the complete documentation index at: https://docs.ankra.ai/llms.txt > Use this file to discover all available pages before exploring further. # Prepare an actor-bound managed-service plan review > Requires the applications rollout flag and live membership intersected with token scopes; reviews require applications.deploy, profiles.read and clusters.read. Preparing a review resolves the immutable package, the declared cluster policy, every explicitly bound consumer and every secret grant on the primary database, and stores an actor-bound plan with a digest and a ten-minute expiry. Confirming accepts only the stored review id and the reviewed digest, revalidates the same authority under row locks, and enqueues one cluster-scoped execution for a customer or existing-service plan; a retry returns the same receipt after current access checks. Hosted plans are refused at preparation: hosted operator-to-customer binding and cell dispatch are not wired, so nothing hosted can be reviewed or confirmed. A name an unreleased service instance already holds on the service cluster is refused with 409 Service name is already in use when the review is prepared, and again when it is confirmed: the reservation made at confirmation decides between concurrent reviews of one name. Service review has changed means only that the digest or the stored review changed. The request body is bounded at 16 KiB, which fits the maximum of 100 consumer_ids, 32 parameters and 16 secret_references. An actor may hold at most 20 open reviews and an organisation 100; a review that was never confirmed is deleted seven days after it expires. Plans never carry credential values. The execution receipt is not proof of service readiness. On a playground, prepare and confirm also check the plan's quota against what the tenant commits now: a shortfall is refused with 409 naming it, and a capacity the platform cannot establish is returned as capacity.state unknown without blocking. ## OpenAPI ````yaml https://platform.ankra.app/openapi.json post /api/v1/org/service-admission/reviews openapi: 3.1.0 info: title: Ankra Platform API version: v1 description: >- The Ankra platform HTTP contract. The /api/v1 surface is the public, bearer-authenticated API used by the Ankra CLI, MCP clients and automation; send a personal or service API token as `Authorization: Bearer `. Browser routes under /org and /chat are served on api.platform.ankra.app (each declares that server); they and /oauth/access authenticate with the ankra_session cookie, and mutations also require the X-Ankra-CSRF header. Every operation declares the credential it accepts, and no operation is served without one. This document is published deliberately: it describes the contract only and carries no organisation data or credentials. Report security issues to security@ankra.ai (see /.well-known/security.txt). servers: - url: https://platform.ankra.app security: - BearerAuth: [] tags: - name: Onboarding description: >- Generate a first website from a prompt and deploy it to a new organisation's cluster. - name: Access Gate description: >- Private service sign-in and membership checks for trusted Ankra proxy relays. - name: Canvas Datasets description: >- Read the fixed, named datasets canvas dashboards bind their charts, tables and stats to. - name: Canvases description: >- Keep dashboards and pages in the organisation's canvas library, with revision history, undo and pins. - name: Canvas Pages description: >- Publish a chat canvas artifact at a public pages address and take it down again. - name: Cloud Delegation description: >- Platform browser consent and organisation-bound connections for Ankra Cloud. - name: Organisation IAM description: >- Custom organisation roles and scoped role assignments for member and service-account identities. - name: Clusters description: Create, inspect and manage clusters, and the stacks deployed on them. - name: Managed Clusters description: Provider-managed control planes, driven through one common surface. - name: Imported Clusters description: Clusters that already existed and were connected to Ankra. - name: Cluster Access description: Kubeconfigs, service-account tokens and per-cluster access grants. - name: Kubernetes description: Read and act on the Kubernetes objects inside a cluster. - name: AWS Clusters description: >- Provision and manage self-managed k3s / kubeadm clusters on AWS EC2 in your own VPC. - name: Ankra Cloud Clusters description: >- Provision and manage self-managed kubeadm / k3s clusters on Ankra Cloud servers: a private network, a NAT router and a bastion per cluster. - name: DigitalOcean Clusters description: Provision and manage DigitalOcean Kubernetes clusters. - name: Hetzner Clusters description: Provision and manage Hetzner Kubernetes clusters. - name: OVH Clusters description: Provision and manage OVH Kubernetes clusters. - name: Scaleway Clusters description: Provision and manage Scaleway Kapsule clusters. - name: UpCloud Clusters description: Provision and manage UpCloud Kubernetes clusters. - name: Applications description: Deploy, configure and observe applications across the fleet. - name: Pipelines description: >- Pipeline definitions, the approval of the authority they declare, and the caches pipelines keep between runs. - name: Workspaces description: >- Personal workspaces on the organisation's CI pool where a repository's heavy commands run, and the repository profiles they are built from. - name: Deploy Targets description: >- Environments, the hosts registered to receive deployments, and the releases deployed to them. - name: Deploy Provenance description: >- Whether an application's deploys verify signed provenance from the organisation's own pipeline, the keys that provenance is signed with, and a dry-run that verifies images without deploying. - name: Backups description: >- Backup vaults, restore points, protection posture and captures for stacks and application deployments; a completed capture is not a verified restore. - name: Stack Profiles description: Reusable stack definitions, their versions and sharing. - name: Services description: >- Versioned service packages and explicit sharing. Runtime admission is separate from publication. - name: Charts description: Browse the chart catalogue behind stacks and addons. - name: Helm description: Helm registries, credentials and the charts they expose. - name: Executions description: Long-running platform executions and their jobs. - name: Operations description: Cancel in-flight cluster operations and their jobs. - name: Chat description: Conversational sessions, plans and confirmable actions. - name: AI Management description: >- Customer agent lifecycle, authenticated identity and organisation automation controls. - name: AI Agent Runs description: Autonomous agent runs and their outcomes. - name: AI Tickets description: The AI ticket board, its sync connections and settings. - name: AI Playbooks description: Reusable playbooks the AI lanes execute. - name: AI Conditions description: Conditions that gate AI autonomy. - name: AI Remediation description: >- The organisation's auto-remediation policy: what the AI lanes may fix by themselves, and who approves the rest. - name: AI Engineering Handoffs description: Work the AI lanes escalate to a human engineer. - name: AI Environment description: The environment and base stacks AI demos deploy into. - name: AI Memory description: >- What the assistant has learned about you: your cross-session memories and learned profile. - name: MCP Servers description: >- Register the MCP servers the organisation's AI agents can call, choose their tools and grant them to roles. - name: Security description: Findings, advisories, SBOMs, compliance and posture. - name: Cost description: Cluster and fleet cost, rate cards and cost settings. - name: Decisions description: >- The decision ledger behind the Security and Cost queues: proposals a surface computed, the approve and set-aside decisions people took on them, and the receipts of running them. - name: Usage description: >- What your organisation used of Ankra - vCPU-hours, playgrounds, managed services, hosted logs and metrics, and AI - per meter and period, with how completely it was measured and whether a published rate applies. - name: Billing description: Subscription and spend caps. - name: Organisation description: Members, invitations, audit logs and organisation settings. - name: Account description: >- Your own account: the contact email Ankra mails when it differs from your sign-in address. - name: Account Tokens description: Personal access tokens for the API and CLI. - name: Credentials description: The shared credential store. - name: AWS Credentials description: >- AWS credentials: access keys or CloudFormation-onboarded STS roles for cost, EKS and self-managed provisioning. - name: Ankra Cloud Credentials description: >- Ankra Cloud API tokens, shared by the self-managed and managed Ankra Cloud lanes. - name: Azure Credentials description: Azure credentials and SSH keys. - name: DigitalOcean Credentials description: DigitalOcean credentials and SSH keys. - name: Hetzner Credentials description: Hetzner credentials and SSH keys. - name: HPE Morpheus Credentials description: HPE Morpheus credentials and the capacity and quotas behind them. - name: OVH Credentials description: OVH credentials and SSH keys. - name: Proxmox Credentials description: Proxmox VE credentials and the capacity and quotas behind them. - name: Scaleway Credentials description: Scaleway credentials. - name: UpCloud Credentials description: UpCloud credentials and SSH keys. - name: Data Source Credentials description: Credentials for metrics and log sources. - name: DNS Credentials description: Credentials for DNS providers. - name: Object Storage Buckets description: >- Buckets Ankra creates and manages on an organisation's own provider credentials. - name: DNS description: DNS zones and records, including custom organisation zones. - name: Cloudflare description: Cloudflare domains and the credentials behind them. - name: Avura description: >- The linked Avura organization, the domains it shares with Ankra Platform, and their DNS records. - name: Variables description: Organisation- and cluster-scoped variables. - name: Secret Slots description: >- Store secrets in Vault and reference them by ${SECRET_SLOT:} sentinel instead of by value. - name: SOPS description: Encrypt and decrypt values with the organisation SOPS config. - name: Alerts description: Alert integrations and ingest credentials. - name: Notifications description: Notification routes and their delivery targets. - name: Support description: Support tickets. - name: AI Settings description: Organisation AI provider, model catalog and per-function model settings paths: /api/v1/org/service-admission/reviews: post: tags: - Services summary: Prepare an actor-bound managed-service plan review description: >- Requires the applications rollout flag and live membership intersected with token scopes; reviews require applications.deploy, profiles.read and clusters.read. Preparing a review resolves the immutable package, the declared cluster policy, every explicitly bound consumer and every secret grant on the primary database, and stores an actor-bound plan with a digest and a ten-minute expiry. Confirming accepts only the stored review id and the reviewed digest, revalidates the same authority under row locks, and enqueues one cluster-scoped execution for a customer or existing-service plan; a retry returns the same receipt after current access checks. Hosted plans are refused at preparation: hosted operator-to-customer binding and cell dispatch are not wired, so nothing hosted can be reviewed or confirmed. A name an unreleased service instance already holds on the service cluster is refused with 409 Service name is already in use when the review is prepared, and again when it is confirmed: the reservation made at confirmation decides between concurrent reviews of one name. Service review has changed means only that the digest or the stored review changed. The request body is bounded at 16 KiB, which fits the maximum of 100 consumer_ids, 32 parameters and 16 secret_references. An actor may hold at most 20 open reviews and an organisation 100; a review that was never confirmed is deleted seven days after it expires. Plans never carry credential values. The execution receipt is not proof of service readiness. On a playground, prepare and confirm also check the plan's quota against what the tenant commits now: a shortfall is refused with 409 naming it, and a capacity the platform cannot establish is returned as capacity.state unknown without blocking. operationId: prepareServiceReviewToken requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/ServiceReviewRequest' responses: '200': description: >- The stored review, its plan and digest; confirmation adds the execution receipt. content: application/json: schema: $ref: '#/components/schemas/ServiceReview' '401': description: Authentication required '403': description: Insufficient permission or missing browser CSRF '404': description: Not accessible, absent, or rollout disabled '409': description: >- Stale revision, missing policy, unavailable deployment binding, deprecated pinned profile, a service name already in use on the service cluster (Service name is already in use), or a playground whose quota cannot admit the service (the detail names the shortfall) '422': description: Invalid or ambiguous request '429': description: >- The actor or organisation already holds the most open reviews it may; confirm one or let it expire '500': description: Internal error '503': description: Rollout availability could not be verified security: - BearerAuth: [] components: schemas: ServiceReviewRequest: type: object additionalProperties: false required: - package_version_id - name - mode - region - data_boundary - cluster_id - consumer_ids - parameters - secret_references properties: package_version_id: type: string format: uuid name: type: string minLength: 1 maxLength: 63 pattern: ^[a-z][a-z0-9]*(-[a-z0-9]+)*$ mode: type: string enum: - hosted - customer - existing region: description: >- Physical cloud region of the placement, for example eu-north-1. It locates infrastructure; it is not the data-location promise, which is data_boundary. type: string minLength: 1 maxLength: 63 pattern: ^[a-z][a-z0-9]*(-[a-z0-9]+)*$ data_boundary: description: >- Boundary the data is permitted to stay within, for example eu. Sharing a service across clusters is decided by this boundary, never by the physical region. type: string minLength: 1 maxLength: 63 pattern: ^[a-z][a-z0-9]*(-[a-z0-9]+)*$ cluster_id: type: string format: uuid description: >- The service cluster for customer and existing modes. Hosted plans cannot be confirmed. consumer_ids: type: array description: >- Customer-mode services can be deployed before connecting an application. Other modes require at least one consumer. minItems: 0 maxItems: 100 items: type: string format: uuid parameters: type: object additionalProperties: type: integer format: int64 secret_references: type: object description: >- Package secret input name to credential grant id. Values are never accepted. additionalProperties: type: string format: uuid ServiceReview: type: object additionalProperties: false required: - id - package_version_id - plan - digest - created_at - execution_id - confirmed_at - capacity properties: id: type: string format: uuid package_version_id: type: string format: uuid plan: type: object description: >- The server-resolved plan (schema version 2): package digest, mode, location, service cluster, consumers with their policy and binding revisions, bounded parameters and opaque secret references. Never credential values. It is exactly the document the digest is taken over, so a planned consumer inside it keeps the stored nil UUID as installation_id; binding_kind says which case applies, and the consumer read reports the same absence as null. additionalProperties: true digest: type: string pattern: ^sha256:[a-f0-9]{64}$ created_at: type: string format: date-time execution_id: type: string format: uuid nullable: true confirmed_at: type: string format: date-time nullable: true capacity: type: object nullable: true description: >- Whether the service cluster can admit the service, as this prepare or confirm assessed it. It describes the cluster at that moment and is not part of the plan or its digest. Only playgrounds are checked, because the platform sets their quota. The service's footprint (for PostgreSQL, its instances and the CloudNativePG operator when the cluster does not run one) is compared with the plan's quota less what the tenant's pods commit now, with the playground LimitRange's defaults applied and the virtual control plane added. Job pods are reported as transient and left out of the decision. A playground that cannot admit the service is refused with 409, and the detail names the shortfall, the namespaces and stacks holding the quota, and what to do. Null when the response assessed nothing: a confirm that returned an existing receipt. additionalProperties: false required: - state - reason - plan_id - quota - committed - transient - required properties: state: type: string enum: - fits - unknown - unchecked description: >- fits: the service fits the playground's quota alongside what is committed now. unknown: the cluster is a playground but the estimate could not be made - its pods watch is not synced and fresh, the read was capped, a quantity is unreadable, a resize is being applied, the engine has no recorded footprint, or it cannot be told whether the shared operator runs; the review proceeds, and this is the warning. unchecked: the platform sets no quota for this cluster, or the package is not a first-party engine; nothing is claimed about its room. reason: type: string description: What decided the state, in sentences. plan_id: type: string description: >- The playground plan whose quota was checked; empty when none was. quota: type: object nullable: true additionalProperties: false required: - limits_cpu_millicores - limits_memory_mib - requests_cpu_millicores - requests_memory_mib properties: limits_cpu_millicores: type: integer format: int64 limits_memory_mib: type: integer format: int64 requests_cpu_millicores: type: integer format: int64 requests_memory_mib: type: integer format: int64 description: >- The plan's quota on the four CPU and memory lines. Null when the decision did not reach it. committed: type: object nullable: true additionalProperties: false required: - limits_cpu_millicores - limits_memory_mib - requests_cpu_millicores - requests_memory_mib properties: limits_cpu_millicores: type: integer format: int64 limits_memory_mib: type: integer format: int64 requests_cpu_millicores: type: integer format: int64 requests_memory_mib: type: integer format: int64 description: >- What the tenant holds now: every admissible, non-terminal pod no Job owns, plus the virtual control plane. transient: type: object nullable: true additionalProperties: false required: - limits_cpu_millicores - limits_memory_mib - requests_cpu_millicores - requests_memory_mib properties: limits_cpu_millicores: type: integer format: int64 limits_memory_mib: type: integer format: int64 requests_cpu_millicores: type: integer format: int64 requests_memory_mib: type: integer format: int64 description: What Job pods hold now; they release it when they finish. required: type: object nullable: true additionalProperties: false required: - limits_cpu_millicores - limits_memory_mib - requests_cpu_millicores - requests_memory_mib properties: limits_cpu_millicores: type: integer format: int64 limits_memory_mib: type: integer format: int64 requests_cpu_millicores: type: integer format: int64 requests_memory_mib: type: integer format: int64 description: What the install adds. securitySchemes: BearerAuth: bearerFormat: PAT scheme: bearer type: http ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.