tapik

tapik lets you describe an HTTP contract once in Kotlin and use that contract to generate typed clients, typed server interfaces, and human-readable documentation.

It is built for teams that want one source of truth for request shape, response shape, and endpoint intent instead of maintaining separate controller signatures, client wrappers, and API notes by hand.

What tapik solves

tapik is useful when your API contract is repeated in too many places:

  • endpoint declarations in one module,

  • client wrappers in another,

  • server interfaces or controllers somewhere else,

  • Markdown or wiki documentation that drifts over time.

tapik replaces that duplication with one Kotlin contract model. Generation then works from the compiled contract, not from copied documentation.

What tapik can do

Area Available

Contract authoring

Define methods, paths, path variables, query parameters, headers, bodies, and outputs in the Kotlin DSL

Client generation

Generate Kotlin clients backed by Spring RestClient

Server generation

Generate Spring Web MVC server interfaces

Codec support

Use built-in scalar codecs and Jackson-backed JSON bodies

Build integration

Run generation through the Gradle plugin

Human-readable docs

Generate a Markdown endpoint summary and publish API reference with Dokka

Where tapik fits well

tapik is a good fit when:

  • your API contract is authored in Kotlin,

  • you want generated artifacts to stay aligned with the code that defines the API,

  • your team values typed request and response models over stringly typed HTTP wrappers,

  • Spring is already part of the stack.

Start from your goal

If you want to…​ Start here

See a complete first result quickly

Quickstart

Decide whether tapik fits your use case

Choose a Goal

Model endpoints cleanly

Model HTTP Contracts

Generate a Spring RestClient client

Generate a Client

Generate Spring Web MVC server contracts

Generate a Server

Review the support overview

Capabilities and Roadmap

The API Reference complements this site. Use the Antora pages for workflow, architecture, and adoption guidance, then use Dokka for API-level detail.