Export the full OpenAPI spec from Apidog including all endpoints, schemas, tags, and Apidog extensions (x-apidog-folder, x-apidog-status, x-apidog-maintainer). Use this to understand the current documentation state before making changes.

List all API endpoints. Returns method, path, summary, tags, folder, status, and maintainer for each. Filterable by tag, path substring, folder, or status.

Get full details of a specific endpoint by method and path. Returns the complete operation object including parameters, request body, responses, examples, and all Apidog extensions. Also returns any referenced component schemas for context. ALWAYS use this before updating an endpoint to understand the existing format.

Search endpoints by keyword across path, summary, description, tags, and folder. Returns matching endpoints ranked by relevance. Use this when you are not sure of the exact path — for example, the user says "the peppol endpoint" and you need to find it.

Create or update a single API endpoint. This is the primary write tool.

WORKFLOW (validated in POC):

1. Exports current spec to preserve existing format

2. Finds the target endpoint — reports if it exists (UPDATE) or not (CREATE)

3. Computes a diff showing exactly what changed

4. Merges the endpoint into the full spec

5. Imports back to Apidog with OVERWRITE_EXISTING

6. Verifies the update landed correctly

IMPORTANT: The operation object must match the Apidog OpenAPI format including x-apidog-* extensions. Always call apidog_get_endpoint first on a similar endpoint to learn the exact format used in this project.

The operation must include x-apidog-orders and x-apidog-ignore-properties arrays in schema objects to match the existing format. See existing endpoints for reference.

Batch create or update multiple endpoints in a single import. More efficient than calling apidog_upsert_endpoint multiple times. Each entry needs method, path, and the full operation object.

Remove an endpoint from Apidog. Exports current spec, removes the endpoint, and re-imports. All other endpoints remain untouched.

Create or update a component schema (data model) in Apidog. The schema is merged into components/schemas. Use $ref to reference from endpoints.

Import a full or partial OpenAPI spec. If mergeWithExisting is true (default), exports current spec first and merges. Use for bulk updates or importing from external sources like Scramble.

Analyze the current folder structure of all endpoints. Returns folder tree, endpoint counts per folder, and endpoints with no folder assigned. Use this as a first step before proposing reorganization.

Propose a better folder organization for all endpoints. Returns a DRY-RUN plan showing what would change — nothing is applied yet. The user MUST validate the plan before calling apidog_apply_reorganization.

Strategies:

• "path-based": Infer folders from URL paths (e.g. /api/v1/admin/billing/... → Admin/Billing)

• "preserve-top-level": Keep existing top-level folders, reorganize sub-levels from URL paths

• "flat": Single level based on main resource name

You can also provide customMappings to override specific path prefixes.

ALWAYS present the plan to the user and ask for confirmation before applying.

Apply a previously proposed and user-validated folder reorganization plan. Takes the changes array from apidog_propose_reorganization. ONLY call this after the user has explicitly approved the plan.