For developers · integrations

The verifier dashboard stays the same. The adapter is what changes.

FieldworkIQ is platform-agnostic at the verification layer. Each supported platform ships as a small adapter that translates inbound messages into a canonical report, then writes verified records back in the platform's own shape. Ushahidi is live today; KoboToolbox and ODK Central are next.

Adapter architecture
One contract on each edge. Everything in between is platform-agnostic.
Inbound adapter
Platform → RawReport

Polling or webhook. Translates the platform's own message shape into a canonical record.

  • inUshahidi messages · Kobo submissions · ODK forms
Verification core
Same for every platform

Translate, classify, geocode, corroborate, sensitivity-check, draft, hand to verifier. Idempotency, audit log, queue model.

  • Smith workflow · Postgres queue · operator console
Outbound adapter
CanonicalRecord → Platform

On verifier approval. Writes the verified record back in the platform's native shape.

  • outUshahidi Posts · Kobo validation · ODK reviewState
No platform forks.
Adapters use each platform's documented API surface.
One verifier dashboard.
The reviewer interface is identical across every connector.
New platform = one adapter pair.
~600 lines of Ruby per platform on the reference Ushahidi build.
Connectors

One adapter pair per platform.

Status updated as we ship. Coming-soon connectors have full design specs in the public repo — feel free to read or contribute.
Shipping

Ushahidi V3

The reference adapter. OAuth2 service account, inbound message polling, outbound Post write with full idempotency. Self-hosted via Docker, tested against Uchaguzi-style deployments.

  • inGET /api/v3/messages?status=pending
  • outPOST /api/v3/posts
  • outPUT /api/v3/messages/{id}
v1.0 · Apache 2.0
Read the integration
Next · Phase 2

KoboToolbox

For humanitarian field surveys that already live in Kobo. Webhook-driven inbound, with poll fallback. Outbound writes set the submission's validation_status and update verified-field metadata.

  • inPOST /api/v2/hooks/{form_uid} (webhook)
  • outPATCH /api/v2/assets/{form}/data/{id}/validation_status
Design spec · in repo
After Kobo · Phase 3

ODK Central

For longitudinal mobile data collection. Polls submissions via OData, writes reviewState updates back. Entities created for verified observations so the rest of the ODK pipeline can pick them up.

  • inGET /v1/projects/{p}/forms/{f}.svc/Submissions
  • outPATCH /v1/projects/{p}/forms/{f}/submissions/{id}
Design spec · in repo
Build your own

Custom adapter

Run a different platform — Aircall, your own SMS gateway, an internal incident tracker? Implement two contracts in ~600 lines of Ruby and FieldworkIQ picks up the connector at boot.

  • inInboundAdapter#poll · #handle_webhook
  • outOutboundAdapter#write · #mark_processed
Apache 2.0 · reference impl in repo
Read the SDK
What every connector inherits

The connector is small. The work it enables is the same on every platform.

An adapter isn't a port of FieldworkIQ. It's a translation layer. Everything verifiers depend on — the queue, the dossier, the corroboration logic, the audit trail, the dashboard — is identical regardless of where reports come from.

Translation & classification

Same multilingual model, same taxonomy mapping, same explainability. New platforms inherit it.

Corroboration logic

Two-source rules, hold thresholds, severity gating. Configured per deployment, applied identically across connectors.

Idempotency & audit

Pre-write checks, run-id stamping, Postgres write log. The same dual-write safety on every platform.

Verifier dashboard

One UI for every connector. A verifier trained on Ushahidi reviews Kobo cases without retraining.

Running a platform we haven't shipped yet?

The repo has the adapter contract, two reference implementations, and a test harness. Most of the work for a new platform is mapping the source's schema to the canonical report — usually less than a day for a developer who knows the platform.

Read the adapter SDK Or talk to us about a custom adapter