Skip to content
DADL

Publish to the Registry

The DADL Registry is an open collection of API definitions. Anyone can contribute a .dadl file by opening a pull request on GitHub.

Before you start

Section titled “Before you start”

Make sure your DADL file:

  • Follows the DADL Specification
  • Has a complete setup block with credential steps
  • Includes coverage metadata
  • Has clear, specific tool descriptions
  • Works against the live API

Step-by-step

Section titled “Step-by-step”

1. Fork the repository

Section titled “1. Fork the repository”

Fork DunkelCloud/dadl-registry on GitHub.

2. Add your DADL file

Section titled “2. Add your DADL file”

Place your .dadl file in the definitions/ directory:

definitions/
├── github.dadl
├── gitlab.dadl
├── shelly-cloud.dadl
├── vikunja.dadl
└── your-api.dadl       ← add here

The filename becomes the URL slug on dadl.ai (e.g. your-api.dadl → dadl.ai/d/your-api).

3. Required metadata

Section titled “3. Required metadata”

Make sure the top-level fields are present:

spec: "https://dadl.ai/spec/dadl-spec-v0.1.md"
credits:
  - "Your Name or Organization"
source_name: "API Name"
source_url: https://docs.example.com
date: "2026-03-29"


backend:
  name: your-api
  type: rest
  description: "One-line description of the API"
  # ...

4. Validate

Section titled “4. Validate”

Run the DADL linter to catch common issues:

Terminal window
go run ./cmd/lint-dadl definitions/your-api.dadl

5. Open a pull request

Section titled “5. Open a pull request”

Push your branch and open a PR against main. The PR should include:

  • The .dadl file in definitions/
  • A brief description of the API and what the definition covers

Naming conventions

Section titled “Naming conventions”
  • Use lowercase kebab-case for filenames: my-api.dadl
  • The backend.name should match the filename (without .dadl)
  • Keep descriptions concise — the AI agent reads them for every tool call

Tips for good definitions

Section titled “Tips for good definitions”
  • Cover the most-used endpoints first — you don’t need 100% coverage
  • Write descriptions for agents, not humans — be specific about what each tool returns
  • Use YAML anchors for repeated pagination and error configs
  • Include depends_on for composites so the dependency graph is clear
  • Document auth quirks in setup.notes (e.g. region-specific URLs, token expiry)

Next steps

Section titled “Next steps”