Skip to main content

KoboToolbox data storage and API

The collection app may work offline, but the project still needs a server when records are synchronised. That distinction matters when an organisation is choosing a field system.

Public server hosting​

KoboToolbox currently provides Global and European Union public servers. Kobo states that data on both public services is stored using Amazon Web Services. Form data is held in a database and submission attachments are held in S3 object storage. The EU service is hosted in Ireland.

Some larger organisations use private KoboToolbox servers, and the platform can be self-hosted.

For an iwi, hapū, marae or Māori organisation comparing systems, record this alongside the same questions asked of ArcGIS Online, QFieldCloud, Microsoft services or any other hosted platform: where the service is hosted, who administers the account, what export is available and how the organisation would leave the service later if needed.

Access to projects​

Current Kobo projects require authentication by default. A project owner can share the project with selected Kobo users and grant specific permissions, or can configure a web form to accept submissions from anybody with the link where that suits the project.

This is separate from deciding who can later view or export the collected records.

Encryption​

Kobo documents encryption in transit and at rest on its public services. It also supports encrypted forms in which submission content is encrypted using a public key before reaching the server and requires the corresponding private key to decrypt it. That option changes what can be viewed, mapped and exported inside Kobo, so it is a design trade-off rather than a generic switch to enable on every project.

Exports and API​

Kobo can export formats including CSV, XLSX and GeoJSON. It also exposes an API that can be used to automate retrieval of project data.

For GIS teams this can support a pattern such as:

Kobo project
   ↓ API/export
staging copy
   ↓ validation
GeoPackage or database
   ↓
QGIS / ArcGIS / reporting

For a small project, a manual GeoJSON export may be entirely sufficient. An API becomes useful when a taiao team or organisation is collecting continuously and wants the GIS to refresh through a controlled repeatable process.

Do not confuse offline collection with local storage​

KoboCollect can collect records without connectivity, and browser forms can also work offline after caching. Once those records are uploaded to a public Kobo server they are hosted there. A local-first requirement therefore needs a different architecture, a private deployment, or a deliberate export-and-retention design.

Official references:

Last reviewed: 26 August 2026

Connect the server choice to the field workflow​

Start with KoboToolbox for field work, then use KoboToolbox to QGIS for exports and Should our hapū use the cloud? when the hosting model matters to the wider system design.

Last updated on