What high-level problem are you trying to solve?
Our app currently has to reconstruct each submission from multiple ODK endpoints. For one submission we currently need to fetch the main payload, XML-derived operational fields, submission metadata, review comments, attachment inventory, and attachment binaries
separately. That makes sync slower, more fragile, and harder to recover when one call fails.
So we therefore have multiple celery queues and chaijning and logging and backfilling in place.
We actually need to keep versioned copies of data that are linked to downstram data that is generated basedd on these collcedt ODK data.
A unified submission bundle would reduce client complexity, cut round trips, and make retry and backfill behavior much simpler.
Current APIs our app has to call
| ODK API | What it is used for | Fields / data used |
|---|---|---|
| Submission list / delta check endpoint | Detect changed or missing submissions and run gap checks | Submission IDs, timestamps for change detection |
| OData submission payload endpoint | Fetch the actual form answers | All form response fields |
| Submission XML endpoint | Fetch operational form metadata | FormVersion, DeviceID |
| Submission metadata endpoint | Fetch submission-level operational metadata | SubmitterID, instanceID, fallback review metadata |
| Review comments endpoint | Fetch ODK review comments | Comment text, reviewer notes, review status |
| Attachment list endpoint | Discover attachment inventory | Filename, presence/absence, attachment metadata |
| Attachment download endpoint | Fetch binary attachment files | File bytes, content type, ETag / cache metadata |
| Attachment conditional request / ETag handling | Skip unchanged files safely | ETag, If-None-Match response handling |
Any ideas on how ODK could help you solve it?
A single submission bundle endpoint would be ideal, or a primary submission endpoint with opt-in includes for related data.
The bundle should ideally include:
- form response payload
- submission metadata
- review state and review comments
- attachment inventory and hashes / ETags
- form version and device metadata
- stable submission identity fields
If one endpoint is not feasible, a documented aggregate contract across the existing endpoints would still help a lot.
- simpler client code
- fewer network round trips
- easier retry and backfill logic
- less risk of partial sync state
- clearer contract for downstream systems
- better performance for large batches
A practical shape could be
- GET /submissions/{id}/bundle
- or a form-scoped endpoint that supports paging and includes related data:
- GET /forms/{formId}/submissions?include=metadata,attachments,comments
If a single endpoint is not desirable, a documented aggregate response contract would still be very useful.
Upload any helpful links, sketches, and videos
Our current Sync dashhboard -
Thanks
Vivek