Summary
The OpenSPP Disability Registry DCI synchronous search endpoint returns a raw HTTP 500 when the DCI envelope contains more than one search_request item.
Single-item search works on the same endpoint. The multi-item request should either return a DCI response envelope with one response item per request item, or return a clean validation error if batching is intentionally unsupported.
Endpoint
POST /dci_api/v1/disability/registry/sync/search
Base tested against the demo server on 2026-05-26:
https://openspp-dci-demo-dr.genete.acn.fr
Steps to reproduce
Send a DCI envelope with header.total_count = 2 and two entries under message.search_request, for example:
{
"signature": "",
"header": {
"message_id": "<uuid>",
"message_ts": "2026-05-26T00:00:00Z",
"action": "search",
"sender_id": "registry-witness",
"receiver_id": "openspp",
"total_count": 2,
"is_msg_encrypted": false
},
"message": {
"transaction_id": "<uuid>",
"search_request": [
{
"reference_id": "<uuid-1>",
"timestamp": "2026-05-26T00:00:00Z",
"search_criteria": {
"query_type": "idtype-value",
"query": {
"type": "NATIONAL_ID",
"value": "<known-existing-national-id>"
},
"pagination": { "page_size": 2 }
}
},
{
"reference_id": "<uuid-2>",
"timestamp": "2026-05-26T00:00:00Z",
"search_criteria": {
"query_type": "idtype-value",
"query": {
"type": "NATIONAL_ID",
"value": "registry-witness-smoke-test"
},
"pagination": { "page_size": 2 }
}
}
]
}
}
Use the same bearer token/header setup that works for a single-item search request.
I can provide the exact test identifiers privately if useful, but avoided including them in this public issue body.
Actual result
The endpoint returns:
HTTP/1.1 500 Internal Server Error
content-type: application/json
{"detail":"Internal Server Error"}
Expected result
One of:
- A DCI
on-search response envelope with two message.search_response entries, preserving reference_id correlation. For example, one succ item for the existing record and one rjct / not-found item for the missing record.
- If multi-item search is not supported, a deterministic 4xx validation response explaining that only one
search_request item is accepted.
A raw 500 makes clients treat the registry as unavailable and prevents safe use of DCI batch search.
Additional interop observations
While testing the OpenAPI surface at /dci_api/v1/openapi.json, I also noticed:
/.well-known/jwks.json is documented for response signature verification but returned {"keys": []} on the demo server. If intentional for the demo, no action needed, but it blocks response-signature verification.
/crvs/registry/sync/search and /farmer/registry/sync/search are documented as accepting DCIEnvelope, but envelope-shaped probes returned 422 validation errors asking for transaction_id and search_request at the top level. If those routes are placeholders, it may be worth documenting that in the OpenAPI descriptions or aligning the request schema.
Context
This came up while integrating Registry Witness with the OpenSPP Disability Registry DCI API as a backend. Single-item Disability DCI search works, and Registry Witness can issue an SD-JWT VC from the returned Disability Registry record. The main blocker for enabling DCI batched search is the 500 on multi-item search_request.
Summary
The OpenSPP Disability Registry DCI synchronous search endpoint returns a raw HTTP 500 when the DCI envelope contains more than one
search_requestitem.Single-item search works on the same endpoint. The multi-item request should either return a DCI response envelope with one response item per request item, or return a clean validation error if batching is intentionally unsupported.
Endpoint
POST /dci_api/v1/disability/registry/sync/searchBase tested against the demo server on 2026-05-26:
https://openspp-dci-demo-dr.genete.acn.frSteps to reproduce
Send a DCI envelope with
header.total_count = 2and two entries undermessage.search_request, for example:{ "signature": "", "header": { "message_id": "<uuid>", "message_ts": "2026-05-26T00:00:00Z", "action": "search", "sender_id": "registry-witness", "receiver_id": "openspp", "total_count": 2, "is_msg_encrypted": false }, "message": { "transaction_id": "<uuid>", "search_request": [ { "reference_id": "<uuid-1>", "timestamp": "2026-05-26T00:00:00Z", "search_criteria": { "query_type": "idtype-value", "query": { "type": "NATIONAL_ID", "value": "<known-existing-national-id>" }, "pagination": { "page_size": 2 } } }, { "reference_id": "<uuid-2>", "timestamp": "2026-05-26T00:00:00Z", "search_criteria": { "query_type": "idtype-value", "query": { "type": "NATIONAL_ID", "value": "registry-witness-smoke-test" }, "pagination": { "page_size": 2 } } } ] } }Use the same bearer token/header setup that works for a single-item search request.
I can provide the exact test identifiers privately if useful, but avoided including them in this public issue body.
Actual result
The endpoint returns:
{"detail":"Internal Server Error"}Expected result
One of:
on-searchresponse envelope with twomessage.search_responseentries, preservingreference_idcorrelation. For example, onesuccitem for the existing record and onerjct/ not-found item for the missing record.search_requestitem is accepted.A raw 500 makes clients treat the registry as unavailable and prevents safe use of DCI batch search.
Additional interop observations
While testing the OpenAPI surface at
/dci_api/v1/openapi.json, I also noticed:/.well-known/jwks.jsonis documented for response signature verification but returned{"keys": []}on the demo server. If intentional for the demo, no action needed, but it blocks response-signature verification./crvs/registry/sync/searchand/farmer/registry/sync/searchare documented as acceptingDCIEnvelope, but envelope-shaped probes returned 422 validation errors asking fortransaction_idandsearch_requestat the top level. If those routes are placeholders, it may be worth documenting that in the OpenAPI descriptions or aligning the request schema.Context
This came up while integrating Registry Witness with the OpenSPP Disability Registry DCI API as a backend. Single-item Disability DCI search works, and Registry Witness can issue an SD-JWT VC from the returned Disability Registry record. The main blocker for enabling DCI batched search is the 500 on multi-item
search_request.