✅ Preliminary Checks
🧩 Problem Statement
Currently, the Swagger documentation in credebl/platform exposes all APIs in a single consolidated view. As the number of APIs grows across multiple domains (e.g., DIDComm, OID4VC, utilities), this leads to:
- Difficulty in quickly locating relevant APIs
- Increased scrolling and navigation time
- Reduced developer experience, especially for new integrators
For example:
- DIDComm APIs (connections, credentials, verification) are mixed with
- OID4VC / OID4VP APIs and
- Utility APIs (geolocation, ledger, webhook, etc.)
This lack of logical segregation makes the documentation harder to use and maintain.
💡 Proposed Solution
Introduce multiple Swagger UI endpoints, each representing a logical grouping of APIs based on feature/domain.
Suggested grouping:
- DIDComm APIs
- Connections
- Credential exchange
Proof/verification
- OID4VC APIs
- OID4VC issuance
- OID4VP presentation flows
Utility APIs
- Geolocation
- Ledger interactions
- Webhooks
- Miscellaneous/shared services
http://localhost:5000/api/didcomm
http://localhost:5000/api/oid4vc
🔄 Alternatives Considered
No response
📎 Additional Context
No response
✅ Acceptance Criteria
No response
✅ Preliminary Checks
🧩 Problem Statement
Currently, the Swagger documentation in credebl/platform exposes all APIs in a single consolidated view. As the number of APIs grows across multiple domains (e.g., DIDComm, OID4VC, utilities), this leads to:
For example:
This lack of logical segregation makes the documentation harder to use and maintain.
💡 Proposed Solution
Introduce multiple Swagger UI endpoints, each representing a logical grouping of APIs based on feature/domain.
Suggested grouping:
Proof/verification
Utility APIs
http://localhost:5000/api/didcomm
http://localhost:5000/api/oid4vc
🔄 Alternatives Considered
No response
📎 Additional Context
No response
✅ Acceptance Criteria
No response