DocDriven

What is DocDriven?

DocDriven is a visual API design platform designed for front-end, back-end, product, and design teams; it is operated by the Danish company Nordicode ApS. It brings together interface design, documentation, mock services, review processes, change logs, and AI-driven code generation in a shared workspace.

The term “design” here refers to the design of endpoints, requests, responses, and data schemas; it does not involve the creation of images, logos, or interface elements. It is useful for aligning API specifications before actual development begins, thereby reducing delays between the front-end and back-end components and avoiding disruptive changes.

Overview of main functions

Visual API design

The team can create endpoints, methods, parameters, request bodies, responses, and data models within the interface, which helps to avoid structural errors that occur when editing YAML directly. Autocomplete and suggestions based on existing attributes assist in ensuring that naming conventions are consistent with the schema.

• Backend developers can determine the resources, error models, and versioning strategies before coding.
• Front-end developers can confirm in advance the fields required for the page and the interaction processes.
• Product managers can view the progress of interfaces, the responsible persons, and unresolved issues.
• UI designers can check whether the data required for the interface is already specified in the contract.
• External visitors can participate in the evaluation of specific projects without needing access to the entire workspace.

Visual editing cannot replace API governance. The team still needs to define rules for authentication, authorization, idempotency, pagination, error codes, rate limiting, and compatibility.

OpenAPI import and unified documentation

New projects can start from scratch or by importing existing OpenAPI specifications. This allows all internal and external interfaces to be brought together in a single workspace, serving as a contract that can be viewed by both the front-end and back-end teams as well as relevant stakeholders.

1. Create workspaces and projects, or choose to import existing specifications.
2. Check whether the endpoints, Schema, examples, and security definitions have been imported completely.
3. Additional business explanations, error responses, and boundary conditions.
4. Invite members or external visitors to provide feedback and assign pending issues.
5. Release the confirmed API version to establish a change baseline.
6. Have the frontend connect to the Mock Server, while the backend implements things in accordance with the agreed specifications.

A successful import does not guarantee that the semantic structure is entirely correct. Circular references, custom extensions, security measures, and complex polymorphic models require separate testing.

How to use a Mock Server

DocDriven enables the creation of immediate cloud-based Mock Servers based on API designs, allowing callers to test requests and responses even before the actual backend is ready. Frontend, mobile, and automated tests can all operate in parallel, all within the framework of the same contract.

• Examples of representative successes, validation failures, unauthorized access, and server errors are provided in response to the definition.
• Do not include production keys, real personal information, or customer data in the examples.
• Verify whether the status code, headers, and latency of the Mock response cover the client logic.
• After the backend is deployed, contract testing is used to compare the actual implementation with the design.

A Mock Server is merely a simulated service; it does not prove that the performance, security, transaction handling, and data consistency of the actual backend meet the required standards.

Real-time collaboration and responsibility management

Team members can view plan changes, comment on interface designs, report issues, and assign responsible persons. Project visitors can only access the projects for which they have been invited; they cannot view other projects or modify the settings of the workspace.

The review records should explain the reasons for the decision, the impact on compatibility, and the migration plan, rather than simply indicating that the task has been completed. When public or partner APIs are involved, formal approval and release procedures must also be in place.

Changelog and Baseline

Baseline captures the state of the API at a specific point in time, and subsequent designs are compared against this baseline. The differences are categorized as new endpoints or schemas, as well as deleted or modified ones, which helps the team identify any changes that might affect the clients as early as possible.

• Establish a clear baseline before a stable release.
• Check for field deletions, type changes, mandatory status alterations, and changes in the request structure.
• Set new versions and migration deadlines for destructive changes.
• Add the business background, release date, and upgrade actions to the Changelog.
• Include differential reviews in the Pull Request or release process.

Automatic diffing can detect structural changes, but it does not necessarily understand the business semantics. Changes in field meanings, default values, or permissions can affect the callers even if the schema remains unchanged.

AI Code Assistant

Code Assistant takes into account the example files and team configurations in GitHub repositories to generate code for the endpoints or schemas in DocDriven. Its goal is to create template implementations based on existing conventions, rather than handling all of the business logic on its own.

Profile requirements

The root directory of the repository must contain docdriven.config.json; each template includes a name, example files, an output directory, and the target type. The target can be Endpoints or Schemas, and the example files serve to indicate the structure and style of the code that will be generated.

Output method

• Create a Pull Request for developers to review before merging it.
• Submitted to the currently selected branch.
• Submit to other branches or other authorized repositories.
• On the log page, you can view the generation process, failure status, and completion status.

Pull Requests should be given priority, with testing, static analysis, and manual review all playing a role in ensuring quality. The generated code may contain errors, excessive permissions, unsafe handling of input data, or implementations that do not comply with business rules.

GitHub Connections and Security

To use Code Assistant, authorization from GitHub is required, so that DocDriven can access the repositories, read code examples, and submit the generated content. The scope of this authorization has a direct impact on private code and supply chain security.

• Only authorize the organizations and warehouses that truly need it.
• Use dedicated branches, protected main branches, and mandatory Pull Request reviews.
• Do not place keys in example files, configurations, or logs.
• Regularly check GitHub application permissions and revoke any connections that are no longer in use.
• Checks for vulnerabilities arising from dependencies, licenses, and malicious packages.
• Access rights are revoked immediately upon departure, completion of a project, or end of the trial period.

Prices and packages

A trial version can be used without a credit card; once it is over, it is necessary to choose a paid plan – otherwise the account will be suspended until a subscription is purchased or the account is closed. The prices shown for Team plans may vary depending on whether payment is made on a monthly or annual basis, as well as taxes and the region in question. Having at least three members means that the minimum cost for a team is higher than the price per individual member.

Upgrades are billed proportionally based on the current billing cycle, while downgrades take effect in the next billing cycle. The public website does not provide clear rules regarding refunds; it is necessary to confirm the details related to renewal, cancellation, unused cycles, and tax handling before making a payment.

Privacy and data processing

The entity responsible for processing data as specified in the privacy policy is Nordicode ApS, with the last update taken in December 2023. The platform handles names, email addresses, account details, payment and usage information; payment data is processed by Stripe, and the terms of service state that the system is hosted in Germany.

• Services may use account information for authentication, delivery, communication, security, and improvement.
• Users may request access to, update, or delete their personal information in accordance with applicable laws.
• The platform states that organizational and technical measures are in place, but it does not guarantee that all risks can be eliminated.
• The services are not designed in accordance with industry-specific regulations such as HIPAA and FISMA, so regulatory teams should proceed with caution.
• GitHub repositories, API design, and generated code may contain trade secrets, and a supplier review should be conducted first.

The privacy page does not provide sufficient information regarding the suppliers of the models used by AI Code Assistant, the retention period for the code, and the purposes for which it is trained. Before accessing private repositories, it is necessary to consult the sales team to understand the data processing agreements, the sub-processors involved, the policies regarding backup and deletion, as well as the policies related to model data.

Terms, Copyrights, and Commercial Restrictions

The terms permit the use of the services for internal business purposes, provided that compliance is maintained, and they reserve the rights to the platform’s code, databases, design, and brand. The platform is not an open-source repository, and a paid subscription does not give the right to copy or resell its services.

• Users should ensure that the APIs, code, and content they upload have the necessary rights.
• Suggestions submitted directly may be transferred to the operators under certain terms; it is necessary to conduct an assessment before sending confidential ideas.
• Public contributions may grant a wide range of usage licenses; private designs should not be placed in public areas.
• Services may experience changes, interruptions, or termination; therefore, the team needs to export the key specifications and create its own backups.
• The terms are governed by Danish law; cross-regional companies should assess their contractual and data-related responsibilities.

Platform, API, and open-source status

Suitable for users and scenarios

• Backend team: Standardize resources, schemas, error handling, and versioning rules before implementation.
• Front-end and mobile teams: Use Mock Servers to develop and test the interfaces in advance.
• Product Manager: Tracks interface plans, reviews issues, and identifies responsible persons.
• Platform engineering team: Maintains consistency across multiple internal and external APIs.
• Technical Lead: Review baseline differences and control destructive changes.
• Teams using GitHub: Generate review-ready template implementations based on the existing code style.

Advantages and capabilities boundaries

Main advantages

• Place API design, Mocking, collaboration, change tracking, and code generation within the same workflow.
• Visual editing lowers the barrier to participation in interface reviews for users who are not part of the backend team.
• Baseline makes the differences between endpoints and schemas more intuitive.
• Code Assistant outputs in the style of repository examples and configuration constraints.
• A 30-day full-featured trial is suitable for testing in real teams.

Main limitations

• Code generated by AI still requires review, testing, and security checks.
• The Team plan, which requires at least three seats, is not suitable for individuals who only need one account.
• A mock server cannot replace real backend testing.
• The model suppliers, details of code processing, platform APIs, and source code are not disclosed.
• The service is not designed for specific highly regulated frameworks.
• The document is still marked as being under continuous improvement; some boundaries may require confirmation from the support team.

Frequently Asked Questions

Is DocDriven an interface design tool?

No. It is designed to handle API endpoints, requests, responses, and data models, and it helps the front-end and back-end work together in accordance with the interface contracts.

Is a credit card required during the trial period?

It’s not necessary. The 30-day trial offers a single workspace along with all functions; once it ends, the account will be suspended if no payment is made.

How many people are minimum required for a Team project?

The current page requires at least 3 paid users; unlimited guests can be invited as well. The total cost will be confirmed on the settlement page.

Can existing OpenAPI be imported?

Projects can be created from existing OpenAPI specifications. After import, it is still necessary to check custom extensions, security definitions, and complex models.

Can a Mock Server be used as a production backend?

No. It is used for simulation design, front-end parallel development, and contract testing; it does not support production-level business logic or data management.

Will AI modify the main branch directly?

The output method can be set to Pull Request, the current branch, or another branch within the repository. Production teams should use protected branches along with mandatory review processes.

Will the generated code comply with the team’s guidelines?

Code Assistant relies on configuration files and example code, but it may still deviate from the rules. Formatting, testing, and manual review are necessary.

Is DocDriven open source?

It is not an open-source product that can be verified. The support for OpenAPI and GitHub integration does not mean that the source code of the platform is available to the public.

Are there public platform APIs?

Currently, no DocDriven API or SDK designed for ordinary developers is available. When automation is needed, it is necessary to first consult the product team.

Is it suitable for medical or highly regulated data?

The terms specify that the service is not designed in accordance with the specific regulations of certain industries. When regulated interfaces or code are involved, compliance and contractual reviews must be carried out before integration.

Summary

DocDriven is suitable for teams that wish to establish shared API contracts prior to coding, and that want to reduce collaboration costs through mocking, difference tracking, and AI-generated sample code. Before making a purchase, it is important to verify the GitHub permissions, the policies regarding model data, the minimum number of licenses required, and the procedures for exporting backups.