Gundi sits between a data source — a satellite network, a LoRaWAN sensor, a drone platform, a digital radio system, a third-party API — and one or more EarthRanger sites. You build against Gundi once, and Gundi handles delivery, multi-tenancy, transformation, and the operational reality of pushing data into production conservation deployments.

If you are building something that produces field data and you want it to land in EarthRanger, Gundi is the supported path.

Why not just call the EarthRanger API directly?

You can, and for a single site with modest volume and a developer who will stay around to maintain it, that's a reasonable choice.

Gundi exists because that shape rarely holds for long:

• Your customers are not one site. If you're a device vendor or data provider, each customer runs their own EarthRanger deployment with its own URL, credentials, and configuration. Gundi makes tenancy a configuration concern instead of something you encode in your product.
• Delivery is not a single POST. Sites go offline, rate-limit, or run different EarthRanger versions. Gundi owns retry, backoff, ordering, and idempotency so every integrator isn't reimplementing the same failure handling.
• Someone has to configure it. Your customers need to enter credentials, choose which feed goes to which site, and map fields — without you shipping an admin console. Gundi's portal provides that surface.
• Integrations rot. APIs evolve on both ends. An integration running in Gundi gets carried forward as the platform changes; a bespoke script in a customer's crontab does not.

What Gundi does today

Ingestion. Three supported patterns:

• Push / webhook — you POST to a Gundi endpoint. Mapping your payload onto EarthRanger's observation and event model is configured rather than coded, using a jq-based transformation builder in the portal. This is how LoRaWAN sources such as The Things Network are handled.
• Pull / action runners — Gundi runs scheduled or triggered Python that authenticates against your API, fetches data, and emits it into the pipeline. This is the usual path for vendor APIs.
• Aggregator fan-in — a single upstream endpoint carrying data on behalf of many end customers is resolved to the correct tenant at the edge, then follows the standard pipeline. This is how satellite beacon aggregators deliver multi-customer position data.

Routing and delivery. Data is normalized, then routed to one or more configured destinations. Gundi manages per-destination authentication and credential lifecycle, delivers with retry and backoff, and enforces idempotency so at-least-once transport doesn't produce duplicate tracks or events.

Configuration and operations. Integrations are created and configured in the portal. Integration state, delivery status, and errors are visible there, so failures surface as operational signals rather than silence.

Proven in production across satellite beacon networks, animal tracking data via Movebank, LoRaWAN sensors, digital radio telemetry, and drone platforms — across hundreds of EarthRanger sites.

Core strengths

1. Tenancy is first-class. One integration per customer is the unit of isolation. Device identity, credentials, and routing are scoped so one customer's data can never contaminate another's.
2. Configuration over code. Field mapping, filtering, routing, and scheduling are configured. You write code only where real logic lives: talking to your own system.
3. Delivery is our problem. Retries, backoff, duplicate suppression, and credential refresh are platform concerns, handled once and correctly, rather than re-solved badly in every integration.
4. A framework, not a pile of scripts. Integrations are built on a shared action-runner framework with a defined contract, so they behave consistently and can be maintained as a class rather than individually.
5. Ecosystem leverage. When EarthRanger or Gundi gains a capability, every integration on the platform inherits it. A direct integration inherits nothing.

Where we're taking it

Gundi is actively developed, and the direction is driven by the integrations people actually bring us:

• Per-site rate limiting and backoff, so a busy or degraded EarthRanger deployment can't affect delivery to any other site. This is the current major platform investment.
• A versioned, distributable integration framework, so building and testing an integration becomes a normal Python dependency workflow rather than something coupled to our release cycle.
• Richer configuration UX, including dynamically populated options — dropdowns filled live from your source system, so your customers select real sites, devices, or projects instead of typing identifiers.
• More expressive query and filtering APIs over event and observation detail.
• Broader source coverage, with recent work on drone platforms and non-position data types such as post-flight imagery.

If you have a use case we don't cover yet, tell us. Integration patterns generally get promoted into platform capabilities once we see the second instance of them.

Getting started

• Docs: Documentation for Developers
• Source / integration examples: github.com/padas/gundi-integration-action-runner
• Request an account or discuss an integration: support@earthranger.com