diid

Appearance

Frequently Asked Questions ​

Common questions regarding diid architecture, CI/CD integration, supported standards, and billing.

Overview & Architecture ​

What is diid? ​

diid is an API connection management and contract protection platform. It tracks service dependencies across your architecture and detects breaking contract changes in CI/CD without requiring developers to write mock unit tests.

Who is diid designed for? ​

diid is built for engineering organizations managing distributed services (typically between 15 and 80 microservices across multiple teams). It bridges the gap between static API catalogs (which cannot gate pull requests) and consumer-driven contract testing frameworks (which impose heavy test authoring and maintenance overhead).

How does diid compare to Pact, Spotify Backstage, and Postman? ​

We maintain a detailed, technical comparison covering setup requirements, CI/CD gating, and maintenance costs in our Alternatives & Comparison guide.

In brief:

  • Unlike Pact, diid does not require developers to write or maintain custom test suites or mock servers. It uses the OpenAPI and AsyncAPI specifications your services already produce.
  • Unlike Backstage, diid is a turnkey platform focused specifically on contract validation and dependency gating in CI/CD, requiring no dedicated platform engineering team.
  • Unlike Postman, diid tracks directional dependencies between services and evaluates contract diffs during pull requests rather than post-deployment.

Does diid require runtime agents or network proxies? ​

No. diid operates strictly at design time and during CI/CD checks. There are no sidecars, agents, or network proxies deployed into your production infrastructure. This ensures zero runtime overhead and no operational risk to customer traffic.

CI/CD & Breaking Change Prevention ​

How does diid detect breaking changes in CI/CD? ​

During a pull request, your CI pipeline invokes the diid-push CLI:

bash
diid-push spec --check

The process executes as follows:

  1. diid-push submits the candidate specification to diid.
  2. diid calculates the semantic diff between the candidate and the current production specification.
  3. diid identifies all downstream services that consume the modified endpoints or event channels.
  4. If an active consumer is affected by a breaking change (such as a removed field, modified type, or deleted route), the command exits with code 1, blocking the pull request.
  5. An alert is dispatched to affected consumer owners via email or Slack.

What if a consumer service does not use the modified field? ​

diid supports endpoint-level and field-level dependency tracking. If Service A modifies /v1/users/billing, but Service B only consumes /v1/users/profile, Service B is not flagged as impacted and the deployment is not blocked.

Can downstream teams approve planned breaking changes? ​

Yes. On Business and Enterprise plans, producers can publish a specification under a pending_approval state. Downstream teams review the exact schema diff and submit digital sign-offs through the web interface. Once all consumers approve, the producer's CI/CD gate turns green.

Supported Specifications & Formats ​

Which API specifications are supported? ​

  • OpenAPI: Versions 3.0.x and 3.1.x (JSON and YAML).
  • AsyncAPI: Versions 2.x and 3.x (Kafka, RabbitMQ, SQS, WebSockets).
  • GraphQL: Schema Definition Language (.graphql).
  • SOAP: WSDL 1.1 and 2.0.
  • Software Bill of Materials (SBOM): CycloneDX 1.2+ JSON.

How are specifications synchronized? ​

  • CI/CD Push: Using the diid-push CLI in GitHub Actions, GitLab CI, CircleCI, or Jenkins.
  • Git Repository Sync: Connecting diid directly to GitHub or GitLab repositories.
  • HTTP Endpoint: Polling live staging or production specification URLs.
  • Manual Upload: Directly uploading files through the web dashboard.

Security & Data Privacy ​

Can APIs be shared with external partners safely? ​

Yes. diid includes Topology Shielding. When you create an Access Grant for an external partner, they only see the shared API specification and documentation. Your internal dependencies, upstream services, and infrastructure topology remain private.

Where is customer data hosted? ​

All diid services, databases, and object storage are hosted in ISO 27001-certified European data centers (Hetzner Cloud in Germany and Finland) under full GDPR compliance.

Is specification data encrypted? ​

Yes. All data in transit uses TLS 1.3. Stored specification files and SBOM records are encrypted at rest using AES-256-GCM.

Is Single Sign-On (SSO) supported? ​

Yes. Enterprise plans support SAML 2.0 and OIDC authentication with Okta, Google Workspace, Microsoft Entra ID (Azure AD), and Ping Identity.

Billing & Subscriptions ​

What happens if an organization exceeds its plan limits? ​

When approaching a project or member quota, an alert appears in your organization settings. Upgrades can be completed in one click under Settings -> Billing. Existing pipelines and verifications continue to run normally.

Have additional questions? Contact our team at info@diid.dev.