Explore, subscribe, and build with our APIs.
A thin relay service that manages repository provider integrations (Azure Repos, GitHub) and ingests their webhook events (code pushes and pull requests) to resume the governed SDLC workflow. It normalizes a provider's webhook payload and forwards the raw pushed branch plus the programme id to resume the workflow; the workflow itself decides release-vs-feature. repo-service is a RELAY, not a decision-maker — it never runs verification or compliance itself. Providers follow a state lifecycle: Pending -> Active (after a successful connectivity test) -> Disabled. Provider credentials (accessToken, webhookSecret) are write-only — never returned in responses.
API analytics and reporting. Tracks API deployments, policies, and operational data for dashboards and insights.
Canonical store for a tenant's architectural substrate — team principles, architecture decision records (ADRs), AI persona definitions, tech catalogue, agent rules, and shared skills. Every AI tool on every team member's machine (Claude / Cursor / Copilot) fetches its team-wide configuration from architecture-service via the typed projections below; personal `.claude/` folders carry only developer-specific ergonomics. Architecture-service is the durable cognitive substrate of the Apiway *Team Layer for AI-First Development*. Principles versions are tracked over time so audits can reconstruct what was in force at any past moment — AI Act Article 12 record-keeping evidence by construction. Lifecycles: Principles (Active → Deprecated). ADRs (Proposed → Accepted → Superseded). Personas (Active → Disabled). TechCatalogueEntries (Trial → Approved → Deprecated → Forbidden). AgentRules and Skills follow a simple Active → Disabled lifecycle.
Manages ticket-platform integrations within tenant organisations. Stores per-tenant provider configurations (Azure Boards, Linear, Jira), exposes a vendor-neutral ticket abstraction, ingests inbound webhooks from providers, and generates ticket backlogs from contract artefacts (OAS uploads, OAS diffs, verification specs, compatibility drift, subscription events). Boards-service is the fourth governance surface of the API-First prerequisite stack (gateway, security, catalogue, boards). Tickets are the durable carrier of work state — including persona-generated output once Tier 3 AI personas ship — so every ticket records its origin (human or persona) and its source artefact (OAS, verification spec, subscription event) for audit and lineage. Providers follow a state lifecycle: Pending → Active → Disabled. Tickets follow: New → Active → Resolved → Closed (with a Cancelled terminal). Provider tokens are write-only — never returned in responses.
Golden-source catalogue of APIs, Products and Prospects published across all tenants. Backs both the internal cloud-ui and the external whitelabelled developer portals — visibility-aware queries return what each caller is permitted to see based on their JWT (own-tenant data + cross-tenant Public or Partner). Specifications (OpenAPI + OpenSLA) are stored per major version per environment and served alongside catalogue entries.
Manages user identities within tenant organisations. Stores profile details, team associations, and lifecycle state. Other services resolve user identity via JWT claims (PrincipalId, email) and call this service to retrieve enriched profile data. Identities follow a state lifecycle: Pending → Active → Disabled or Superseded. Changing a PrincipalId creates a new record and supersedes the old one.
Manages API consumer clients and their contacts within tenant organisations. A "client" is an organisation or entity that consumes APIs through Apiway — this service is the authoritative directory for client profiles and their contact persons. Clients support soft-delete (archiving) and verification status. Contacts are nested under clients and represent named individuals with email addresses. All mutation operations support conditional requests via If-Unmodified-Since for concurrency control.
The master orchestrator for the Apiway platform. Manages the full lifecycle of APIs — from prospect registration through governance approval, OAS specification management, gateway deployment, consumer subscription, and version retirement. This is the authoritative source of record for all API catalogue, deployment, and subscription state. Coordinates with gateway workers (Alpha, Azure, Apigee, Kong) via WebSocket for deployment execution, and enforces governance approval flows before critical operations.
Runtime mock server for the Apiway platform. Accepts HTTP requests with metadata headers identifying an OpenAPI specification, resolves the matching operation, validates the request against the OAS schema, and returns a schema-based mock response with realistic random values.
Internal tenant administration and consumer management. Handles tenant provisioning, billing, payment processing, identity integration, and sign-up workflows.
Tracks billable resource units emitted by Apiway services. Every write operation across the platform (deployments, subscriptions, design submissions, etc.) records an RU event here. Provides summaries for billing dashboards and cost analysis. Also runs scheduled jobs for recurring (monthly/quarterly/annual) cost entries.
Pre-computed risk accelerator for the Apiway platform. Receives batched operational risk events from API gateways, classifies and aggregates them per tenant/API, and serves pre-computed risk summaries for dashboards and NIS2 incident response.
API design recommendations and standards library. Analyses OpenAPI specifications against design standards and provides structured improvement suggestions.
Manages the organisational chart for Apiway tenants. Provides the hierarchy of Groups → Functional Areas → Teams and a catalogue of Functions (capabilities). Other services reference this structure to scope data and permissions to organisational units.
Manages scope and role entitlements for API consumers and users. Entitlements define what a client (API consumer subscription) or identity (user from identities-service) is authorised to access, anchored to an organisational context (application, version, functional area, group, team). This service is the authorization mapping layer — it does not own identity or client data. Identities come from identities-service (golden source), clients come from clients-service (subscription consumers). Entitlements-service maps them onto scopes and roles via delegates. Delegation model: an EntitlementDelegate links an Entitlement + Client + optional Identity, with an optional approval workflow (DelegateApproval).
AI-powered API design intelligence for the Apiway platform. Generates OpenAPI specifications from business context (functions, capabilities, and requirements), analyses coverage gaps in the API landscape, and suggests new API opportunities. Also provides specification improvement — uploading an existing OAS and receiving an enhanced version with platform standard compliance.
Manages gateway instance registry — CRUD for gateway instances, credentials, environment settings, identity providers, API keys, and notification templates across multiple gateway provider types (Azure APIM, Apigee, Kong, Apiway Alpha). Workers query this service to resolve gateway connectivity details at deployment time.
The service to handle the data history
Runtime request/response validation against OpenAPI specifications. Called by the gateway during API traffic to check whether actual HTTP payloads conform to the API contract. Produces scored violation reports covering path, method, query parameters, headers, request bodies, response status codes, and payloads. Results are persisted for audit and analytics. Supports dual JWT authentication — service-to-service (issuer: apiway.net) and gateway-origin requests (issuer: gateway.apiway.net).
Manages credit balances for Apiway tenants. Credits are purchased via Stripe or added manually, and consumed against resource unit costs. Provides credit transactions, per-tenant balance summaries, and is called by admin-service for payment reconciliation.