> For the complete documentation index, see [llms.txt](https://docs.dcn.foundation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dcn.foundation/part-vi-developer/06-developer/17-api-overview.md). # 17. API Overview > *The DCN API provides a standardized interface for interacting with Physical Digital Assets, Publishers, Verification Services, and blockchain networks. It enables applications to build interoperable DCN solutions without requiring knowledge of protocol internals or blockchain-specific implementations.* *** ## Introduction While SDKs provide high-level development libraries, APIs provide **language-independent access** to the DCN ecosystem. The DCN API allows applications to communicate with: * Companion Wallets * Publisher Platforms * Verification Services * Asset Registry * Blockchain Adapters * Payment Services * Lifecycle Management * Certificate Infrastructure Applications written in any programming language can integrate with the DCN ecosystem using these standardized APIs. Whether building: * Mobile applications * Enterprise systems * Government portals * Banking platforms * Merchant systems * Manufacturing systems * Web applications * Cloud services the interaction model remains consistent. *** ## Purpose The API architecture is designed to: * Standardize communication * Reduce integration complexity * Support interoperability * Provide language independence * Enable cloud-native deployments * Simplify ecosystem integration * Ensure security by default *** ## API Architecture ```mermaid flowchart TB Applications REST["REST API"] SDK["SDK Layer"] Gateway["DCN API Gateway"] Wallet["Wallet Service"] Publisher["Publisher Service"] Verification["Verification Service"] Registry["Asset Registry"] Blockchain["Blockchain Adapter"] Applications --> REST Applications --> SDK REST --> Gateway SDK --> Gateway Gateway --> Wallet Gateway --> Publisher Gateway --> Verification Gateway --> Registry Gateway --> Blockchain ``` The API Gateway provides a single entry point into the DCN ecosystem while routing requests to the appropriate service. *** ## API Design Principles The DCN APIs follow several core principles. #### REST First All services expose RESTful APIs using standard HTTP methods. #### Resource Based Every object is represented as a resource. Examples include: * Assets * Wallets * Publishers * Certificates * Transactions * Ownership * Verification #### Stateless Each request contains sufficient information to be processed independently. #### Versioned All APIs include explicit version numbers. Example: ``` /api/v1/assets /api/v1/wallets /api/v1/verification ``` #### Secure Every sensitive endpoint requires authentication and authorization. *** ## API Categories The DCN Standard defines three primary API groups. | API | Purpose | | ----------------- | ---------------- | | Wallet APIs | User interaction | | Publisher APIs | Asset management | | Verification APIs | Trust validation | Additional APIs may be introduced in future versions of the standard. *** ## Common API Structure All DCN APIs follow a consistent request model. ```http POST /api/v1/resource Headers Authorization Content-Type X-Request-ID Body JSON ``` *** ## Standard Response Every API returns a standardized response object. ```json { "success": true, "requestId": "REQ-12345", "timestamp": "2027-08-01T10:30:00Z", "data": { }, "errors": [ ] } ``` This response format simplifies client development across all services. *** ## Authentication Sensitive APIs require authentication. Supported mechanisms may include: * OAuth 2.1 * JWT * Mutual TLS * API Keys * Publisher Certificates * Merchant Certificates The authentication method depends on the deployment environment. *** ## Error Model All APIs return standardized error responses. Example: ```json { "success": false, "errorCode": "DCN-4010", "message": "Invalid Publisher Certificate" } ``` Standardized errors improve interoperability and simplify troubleshooting. *** ## API Versioning The DCN Standard follows semantic API versioning. ``` v1 Major version ↓ Minor additions ↓ Backward compatible updates ``` Breaking changes require a new major version. *** ## Security Every API should support: * TLS 1.3+ * Digital Signatures * Certificate Validation * Rate Limiting * Audit Logging * Request Signing * Replay Protection Security requirements apply consistently across all API groups. *** ## Relationship to Following Sections This chapter introduces the three core API families: * **Wallet APIs** — Companion Wallet interaction. * **Publisher APIs** — Issuance and lifecycle management. * **Verification APIs** — Trust validation and authenticity. Together they define the primary integration surface of the DCN ecosystem. *** ## Summary The DCN API provides a standardized, secure, and language-independent interface for interacting with the entire DCN ecosystem. By exposing consistent APIs for wallets, Publishers, verification, and blockchain infrastructure, the DCN Standard enables developers to build interoperable applications across every supported platform and industry. *** ## In this chapter * [Wallet APIs](/part-vi-developer/06-developer/17-api-overview/wallet-apis.md) * [Publisher APIs](/part-vi-developer/06-developer/17-api-overview/publisher-apis.md) * [Verification APIs](/part-vi-developer/06-developer/17-api-overview/verification-apis.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.dcn.foundation/part-vi-developer/06-developer/17-api-overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.