What the hub holds, and how it's organised.
The Regional Hub brings the region's soil-health and fertiliser data into one governed platform — its Central Data Infrastructure. It doesn't re-host data; it federates across the systems that already hold it — each country's National Soil Information Systems (sovereign, connected under agreement) and the wider research commons — and serves it back out through a secured gateway as the catalogue's Data, Knowledge and Tools. Every connection is a written, versioned contract with a named owner.
Not everything is open — but a lot is. Open data, knowledge and tools you can use freely under their licence; other datasets you request under a data-sharing agreement, so ownership, purpose and terms stay clear on both sides; and the internal governed core is never exposed directly.
Start with your role.
The platform serves very different people. Find yourself below and go straight to what you need — most paths need no account.
Researchers & analysts
Find, understand and request datasets to analyse, publish and cite.
Find data →Extension officers & agronomists
You don't need the docs — open the ready-to-use maps and fertiliser advice. No account.
Open the tools →Development partners
Request data and advisory outputs to run field programmes — and track whether they work.
Request access → · Impact →Governments & policy makers
See coverage and evidence for planning — and connect your national soil system, which your country keeps and controls.
Impact & coverage → · Connect a system →Regional bodies — ECOWAS & the AU
One shared picture across member states, with every country keeping its sovereignty.
How it fits together → · Coverage →Developers
Call the secured API with a key to pull data products into your own tools.
Quickstart → · API reference →How the fabric works.
The Central Data Infrastructure doesn't collect or re-host data — it federates across the systems that already hold it and governs the way in. It draws on two families of sources: each country's own National Soil Information Systems, and the wider research commons (CGIAR's Dataverse and GARDIAN, plus open global layers). Country data stays with the country; the commons is connected, not copied; and the platform honours every data-sharing agreement at the door.
Sources 1 — National systems
Each country's own soil-information system (Ghana, Liberia, Sierra Leone; Nigeria next). The data stays with the country — sovereign — and the platform connects to it under a data-sharing agreement.
Sources 2 — The commons
Regional and global reference data stored and cited in Dataverse (DOIs, versioning) and made findable through GARDIAN, plus open layers like SoilGrids and iSDA. The hub's Knowledge products are a branded regional lens on GARDIAN — a filtered view, not a copy.
Govern & serve — CDI
The CDI is the front door: it federates across both, enforces each dataset's agreement on every request, and serves the data, knowledge and tools you see in the catalogue.
Why the catalogue is typed: Data · Knowledge · Tools.
The hub's job is better fertiliser advice and soil health — so every product is typed by what you do with it: Data is the raw, analysis-ready material (soil properties, trials, National SIS data) for analysing, modelling and building; Knowledge is evidence made sense of (publications, syntheses, guidance) for deciding and learning; Tools are ready-to-use services (maps, advisories, dashboards) that turn the data into an answer, no data-wrangling needed. The tabs on the catalogue are exactly these three.
Three ways in, depending on who you are.
Browse
Anyone can explore the catalogue to see what exists — datasets, coverage, formats and who owns them. No account needed.
Open the catalogue →Request
Researchers, governments and partners request access to a dataset under a data-sharing agreement. The hub team confirms the terms.
How to request →Build
Developers call the secured API gateway with a key to pull data products into their own tools.
Developer quickstart →Find data.
One place lists every dataset — the hub's own systems plus federated soil-data layers it references, many stored in Dataverse and discoverable through GARDIAN. Search by name, theme or format, and filter by access level, theme or coverage. Each entry opens a panel with everything about that dataset.
Understand a dataset.
Open any dataset and its panel tells you what you're looking at — so you can judge whether to trust and use it before requesting access.
Metadata
Steward (who owns it), coverage, time period, update cadence, formats, licence and DOI.
Field schema
The columns you'd receive — each field's name, type, unit and meaning.
Lineage
Where the data comes from, and where it flows next.
FAIR & citation
A FAIR-maturity score and a ready-to-use citation for every dataset.
Access levels & licensing.
Each dataset states its own access level and licence. Here's what they mean.
| Access level | What it means | Typical licence |
|---|---|---|
| Open data | Freely downloadable and reusable with attribution. | CC-BY-4.0 |
| By agreement | Available under a data-sharing agreement — request access and the team confirms terms. | Data-sharing agreement |
| Internal | The governed core — not offered externally; its data reaches you through the delivery products. | Not distributed |
Freshness, versions & citing.
Every live dataset carries a freshness signal so you know whether it's current, and a version so you can cite exactly what you used.
Fresh · Due · Overdue
Compared to each dataset's expected update cadence: within cadence = Fresh, a little late = Due, well past = Overdue.
Versions & DOIs
Datasets carry a version tag and, where minted, a DOI — so a citation points at an exact release.
Citation
Each dataset panel shows a ready-to-paste citation crediting the steward and version.
Request access — no code required.
Access is arranged under a data-sharing agreement so ownership, purpose and terms are clear. This path is for researchers, governments, partners and national soil systems — anyone who needs the data itself, not the API.
Tell us what you need
Open a dataset and use “Request access”. Include your organisation and how you'll use the data — a couple of minutes.
We agree the terms
The hub team confirms scope and the data-sharing terms with you.
You get secured access
Delivered through the secured gateway, under agreement. Connecting a national system? That's a bilateral agreement — you keep control of your data.
Quickstart — from catalogue to call.
For developers building on the hub. Discover datasets from the machine-readable catalogue, then call the secured API gateway with a token you obtain by requesting access.
# 1 · discover — the machine-readable DCAT catalogue (public)
curl https://data.rh-fsh-was.iita.org/data.json
# 2 · sign in & request access, then create an API key below
# 3 · call the secured API gateway
curl -H "Authorization: Bearer <your-key>" \
https://api.rh-fsh-was.iita.org/v1/datasets/LIMSAuthentication.
You sign in once — through Guardian SSO (email) or CGIAR Entra ID — and the gateway issues a signed, httpOnly session cookie. What you can reach is decided separately: every dataset is an explicit access grant (scope + validity) issued by the owning team. Authentication says who you are; grants say what you may touch. Both are checked on every gateway call.
Sign in once
Guardian SSO (email) or CGIAR Entra ID, behind one login at the gateway. Tokens live in a signed httpOnly cookie the browser never sees.
Authorization = grants
Access to each dataset is a grant from the owning team, checked on every call. A valid session or key alone is not access — you also need a grant.
API key (gateway)
Send Authorization: Bearer rhk_… to /api/v1/*. A key carries your identity and the same grants — optionally scoped to a subset. Per-user, revocable, never in a URL.
API keys.
Keys authenticate your calls to the secured gateway. The full key is shown once at creation — copy it then. Revoking a key stops any application using it immediately.
Your API keys
API reference.
Public endpoints need no authentication. Gateway endpoints (/api/v1/*) require an API key; key-management endpoints require a signed-in session. All responses are JSON over HTTPS unless noted.
Data standards & formats.
The catalogue is published to open, international standards and is harvestable by other registries — the hub is a federating node, not another silo.
DCAT-US
/data.json is a live DCAT-US catalogue — the feed data.gov and CKAN speak.
schema.org
Catalogue pages embed schema.org Dataset JSON-LD, so datasets surface in Google Dataset Search.
FAO GloSIS
Soil datasets declare conformance to FAO GloSIS (ISO 28258).
Harvestable
Harvestable by CKAN, HDX and CGIAR GARDIAN; a sitemap lists every dataset.
Contributing back
The hub feeds the commons too: /contribute.json is a DCAT feed of the hub's own datasets for GARDIAN to harvest. Sovereign national-system data is never contributed — only the hub's own.
Rate limits & conventions.
Public and write endpoints are rate-limited per client. Exceeding a limit returns 429 Too Many Requests; back off and retry. Catalogue reads are cached and generous.
| Endpoint | Limit | Notes |
|---|---|---|
| GET /data.json | cached ~5 min | Read freely; served from cache. |
| GET /api/systems | cached ~15 s | Public roster. |
| POST /api/keys | 12 / hour | Per signed-in user. |
| POST /api/requests | 6 / 10 min | Access & agreement enquiries. |
Errors are JSON with an error field. 401 = missing/invalid key or session; 403 = not entitled; 404 = unknown; 429 = rate-limited.
Governance & terms.
Trust is built into the pipeline, not bolted on. National data sovereignty, named ownership on both sides, versioned interface contracts, responsible-AI review and agronomic sign-off apply across every stage. Every partnership runs under the data-protection law of the country involved and the region's frameworks (ECOWAS, the African Union), with GDPR principles as the baseline.