AgriStack: India's Digital Public Infrastructure for Agriculture, A Complete Guide for Agritech Companies, Developers & Founders
- PRODCX Team
- Jun 11
- 13 min read
If you're building anything in Indian agriculture, whether it's a lending product, a machinery booking platform, an input marketplace, or a crop advisory app — AgriStack is the single most important piece of infrastructure you need to understand right now.
This guide breaks it all down. Honest walkthrough of what AgriStack is, how it works, and how your team can actually build on it.
Let's get into it.
What Is AgriStack, Really?
Most people hear "AgriStack" and think it's a big government database. It's not.
AgriStack is a federated, consent-driven data exchange protocol for Indian agriculture. Think of it like UPI, but for farmer data. Just like UPI didn't store your money but created the rails to move it, AgriStack doesn't centrally store farmer data, it creates the rails to securely share it, with the farmer's permission.
At its core, AgriStack answers three fundamental questions:
Who is the farmer?
Where is the land?
What crop is growing on it?
These three questions are answered by three foundational registries, what the architecture calls the Golden Triangle.

The Golden Triangle: Three Registries That Power Everything
1. The Farmer Registry
Every farmer enrolled in AgriStack gets a unique identifier called a FrUID, an 11-digit number with a Verhoeff checksum digit at the end. This becomes the farmer's digital identity across all government schemes and private services.
The FrUID is linked to:
Aadhaar (for identity verification and deduplication)
PM-KISAN beneficiary data
PMFBY (crop insurance) records
Bank account details (for direct benefit transfers)
The system uses a Name Match Score powered by C-DAC to deduplicate farmers:
Score ≥ 80: Auto-approved
Score 31–79: Manual review
Score ≤ 30: Rejected
It also handles multi-script transliteration across all 22 Indian languages, which is critical given how farmer names are recorded differently across documents in different states.
As of today, 8.48+ crore Farmer IDs have been generated across India.
2. The Geo-Referenced Village Maps Registry
Every agricultural plot in the country is being mapped with a unique Farm ID, a 14-character identifier structured as:
2 characters: State code (e.g., OD for Odisha, MH for Maharashtra)
11 characters: Unique random number (state-level)
1 character: Verhoeff checksum
Each Farm ID carries:
GeoJSON polygon (the actual shape of the land)
Owner name and land extent
Land use classification
Irrigation source
Soil type
This data is sourced from cadastral maps, ESRI India GIS tools, and ISRO NRSC satellite imagery. The coordinate system is WGS84, which is standard GPS format, meaning it directly integrates with any mapping or navigation system you're building.
3. The Crop Sown Registry (via Digital Crop Survey)
This is the live, season-by-season registry of what's actually growing on each plot. It's updated every Kharif and Rabi season through a process called the Digital Crop Survey (DCS).
Each record looks like this (simplified):
Farmer ID + Farm ID + Season + Crop ID + Sown Area + Date of Sowing + Geo-tags + Irrigation Type
As of Kharif 2025, 28.5+ crore plots have been surveyed across 604 districts.
The Architecture Behind It All: InDEA 2.0
AgriStack is built on InDEA 2.0 — India's Digital Ecosystem Architecture. The important thing to understand here is that InDEA 2.0 is not a single system. It's a set of design principles for building trustworthy digital public infrastructure.
Key principles that directly affect how you build on AgriStack:
Federated Architecture: States own and maintain their registries. The Centre provides the API standards and the exchange layer. This means data is never in one central place.
Open API by Default: All access goes through standardized REST APIs.
Privacy by Design: Compliance with DPDP Act 2023 is baked into the design.
Mobile First: The entire system is designed for field surveyors, farmers, and operators using smartphones.
Cloud First: State workloads run on VPCs; sensitive central data runs on Meghraj (India's government cloud).
The practical takeaway: states are the legal custodians of registry data. When you integrate, you're not talking to one central server, you're talking to a network of state registries through a unified API gateway.
UFSI: The API Gateway You'll Actually Integrate With
Everything flows through one interface: the Unified Farmer Service Interface (UFSI).
UFSI has three components:
API Specifications Layer — defines all data schemas in OpenAPI 3.0 format, error codes, versioning, and call sequences
Network Manager — handles service discovery, load balancing, traffic routing between states and central systems
Access Manager — manages OAuth 2.0 tokens, scope-based authorization, rate limiting, and immutable audit logs
Key APIs You'll Use (This may change based on the updates, look into the real sources)
What You Need | Endpoint | Scope Required |
Farmer profile | GET /v1/farmers/{frUID} | farmer:read:basic |
All land parcels of a farmer | GET /v1/farmers/{frUID}/land-holdings | land:read:ownership |
Plot shape and attributes | GET /v1/plots/{farmID} | land:read:geometry |
Current season crop on a plot | GET /v1/crops/plots/{farmID}/seasons/current | crop:read:current |
Multi-season crop history | GET /v1/crops/history/{farmID} | crop:read:history |
Initiate consent request | POST /v1/consent/request | consent:write |
Check consent status | GET /v1/consent/status/{requestID} | consent:read |
How Authentication Works
AgriStack uses standard OAuth 2.0 Client Credentials flow:
You send your client_id and client_secret to the UFSI auth endpoint
You receive a JWT access token (valid for 60 minutes)
Every API call includes this token in the Authorization header
For private farmer data, you also need to include a Consent Artefact (explained below)
The Consent Manager: Why This Is Not Just "KYC"
This is where AgriStack differs fundamentally from traditional KYC systems. AgriStack uses a DEPA-compliant Consent Manager, based on the same Data Empowerment and Protection Architecture used in India's Account Aggregator framework.
Here's the key principle: the farmer controls their own data.
Before your platform can access any farmer's registry data, the farmer must explicitly approve it through the Consent Manager app. They get to choose:
Which specific data fields you can access
What purpose the data will be used for
How long you're allowed to access it (max 1 year by default)
The output of this approval is a Consent Artefact, a digitally signed JSON document that proves the farmer agreed. You pass this artefact as a header in every UFSI API call that accesses personal data.
Critical things to know about consent:
It's granular — farmers can allow you to see crop data but not soil type, for example
It's revocable — the moment a farmer revokes consent, your access is cut off instantly
The Consent Manager is data blind — it never sees the actual data, only the metadata about what was consented to
All consent events are logged in immutable audit trails with 7-year retention
For your developers: you initiate a consent request via API, and the farmer gets a push notification on the Consent Manager app. Once they approve, you receive the signed Consent Artefact and can start making data calls.
How the Digital Crop Survey Actually Works
Understanding DCS matters because the data quality of the Crop Sown Registry depends on it.
Here's the ground-level process:
Before the season (T-30 days): Village maps and Farmer Registry data are synced into the system. Each surveyor is assigned roughly 500 plots.
During the survey window (~45 days): Surveyors use a mobile app to visit each plot. For each plot, they:
Must be physically inside the plot polygon (GPS geofence enforced, ±10 meters tolerance)
Select the crop from a standardized dropdown (no free-text — prevents naming inconsistencies)
Enter sown area, date of sowing, and irrigation type
Take 3–5 geotagged photos
The app runs an AI validation on-device: does the photo match the reported crop?
Quality assurance is layered:
10% random supervisor review per surveyor
Mandatory 20% spot-check by Inspection Officers across every taluka every season
Central monitoring dashboard with real-time coverage heatmaps and anomaly alerts
After the season: Data is frozen, cross-validated with ISRO satellite imagery, and written to the Crop Sown Registry.
For your platform, this means: the crop data you pull via UFSI is not self-reported, it's field-verified with satellite cross-check. That's a significant data quality improvement over anything available before.
How to Get Access: The Developer Journey
Here's the step-by-step path from zero to production.
Step 1: Register on the AgriStack Developer Portal
Create an account, describe your application, and specify your use case and data scope. The Ministry of Agriculture (MoAFW) reviews your application.
Step 2: Get Sandbox Credentials
Once approved, you receive a client_id and client_secret for the sandbox environment.
Sandbox specs:
10,000+ synthetic farmers, 50,000+ plots, multi-season crop data
100% API parity with production (same auth, same rate limits, same error codes)
Consent Simulator that auto-approves consent requests for testing
State emulation for UP, Maharashtra, Odisha, MP, and others
Rate limit in sandbox: 100 requests/minute per client.
Step 3: Build and Test
Build your integration. Some things your code must handle:
Token refresh before the 60-minute TTL expires
Retry with exponential backoff for 429 (rate limit) and 5xx responses
Idempotency keys for write operations
Graceful degradation if a state registry is temporarily unavailable
Proper Consent Artefact header on every personal data call
Step 4: Security Audit
Before production credentials, you must pass a security audit by a CERT-In empaneled auditor. This covers TLS configuration, secrets management, data handling practices, and DPDP Act compliance.
Step 5: Certification and Production Access
Pass the audit, receive your UFSI Compliance Badge, and get production credentials. Production rate limits scale with your tier:
Tier 1 (verified agri-fintech / bank): 1,000 requests/minute
Tier 2 (high-volume platforms): 10,000 requests/minute
Tier 3 (government systems): 100,000 requests/minute
Real Use Cases: What You Can Build
Use Case 1: Machinery Booking Platform (RaaS)
This is one of the most powerful applications of AgriStack's land geometry data.
With the farmer's consent, your platform can:
Pull the exact GeoJSON polygon of each plot
Know what crop is growing and at what stage
Know the soil type and irrigation setup
Run a matching algorithm: which tractor, harvester, or sprayer is the right fit for this plot?
Your matching logic can factor in:
Plot size vs. machine's minimum economic working area
Crop compatibility (not every machine works for every crop at every stage)
Slope (calculated from DEM overlay on the geometry)
Soil compaction risk (heavy machines on waterlogged clay = damage)
After the operation, you can verify completion using GPS telemetry against the plot polygon, tamper-proof proof of work, no disputes.
The business case: A typical RaaS platform targeting 500,000 hectares at ₹2,500/hectare/season at 15% platform take-rate generates roughly ₹375 crore/year in gross revenue. The farmer saves ₹2,125/hectare versus manual booking.
Use Case 2: KCC in 30 Minutes
Kisan Credit Card applications currently take weeks and multiple branch visits. With AgriStack, here's what the flow looks like:
Farmer initiates application on your fintech app
Your app requests consent for: farmer profile, farm IDs, crop history, land extent
Farmer approves in the Consent Manager app (one tap)
Your app pulls all three data points simultaneously via UFSI
Auto-populate the loan application — no manual entry
Run the credit scoring model using land extent × crop history × MSP price × previous claim history
Generate a pre-approved offer
Farmer e-signs with Aadhaar OTP
Disbursement to linked account
Total time: under 30 minutes.
This has already been piloted with farmers in Farrukhabad and Varanasi.
Use Case 3: Input Marketplace with Demand Aggregation
Traditional input distribution is fragmented and expensive.
AgriStack enables a different model:
Pull crop data for all consented farmers in a village
Calculate actual input requirements per plot (using ICAR's package-of-practices standards): seed quantity, NPK fertilizer, pesticide
Aggregate total demand at village level
Go to suppliers with bulk demand, negotiate 15–25% better prices
Route delivery to last mile
The data quality here is the difference-maker. You're not estimating demand from surveys you're calculating it from verified plot area, crop type, and growth stage.
Use Case 4: Carbon Credit Platform
This is an emerging use case with significant revenue potential.
AgriStack's multi-season crop history creates the baseline needed for carbon MRV (Measurement, Reporting, Verification):
What was grown on this plot for the past 3–5 seasons?
Was it no-till? Cover crop? Intercropping?
What's the soil carbon trajectory?
With verified historical data, you can originate carbon credits in the ₹500–2,000/tonne CO2e range and provide farmers a revenue stream outside of crop sales.
How AgriStack Reduces Your CAC by 90%
Let's be direct about the business impact.
Traditional agritech customer acquisition:
Field sales force: ₹2,000–5,000 per farmer
Manual KYC and land verification: ₹500–1,000
Demo plots and farmer meetings: ₹1,000–2,000
Total: ₹3,800–8,800 per farmer
AgriStack-enabled acquisition:
API-based onboarding: ₹50–100
Instant FrUID + Farm ID verification: included in API cost
Consent-based data pull: ₹0 (built into the platform)
Hyper-local targeting by village/plot/crop: ₹100–200
Total: ₹150–400 per farmer
That's a 90–95% reduction in CAC, with payback period dropping from months to weeks.
More importantly, you're not guessing at targeting anymore. You know exactly which farmers in which village are growing paddy at harvest stage, have plots over 2 hectares, and haven't taken a KCC in the last 2 years. That precision is not possible with field surveys.
How AgriStack Connects to Other Systems
AgriStack doesn't work in isolation. It's designed to plug into India's broader agricultural data ecosystem.
AgriStack → K-DSS (Krishi Decision Support System):
Plot geometry + crop sown + farmer ID feeds into K-DSS's analytics engine, which combines satellite imagery, weather, and soil data to generate plot-level advisories. The integration flows both ways, K-DSS pest alerts can trigger farmer notifications through AgriStack's consent-based notification layer.
AgriStack → eNAM (Electronic National Agriculture Market):
At harvest time, verified crop data automatically lists a farmer's produce on eNAM, crop type, quantity estimate, grade, availability window without the farmer needing to do any paperwork. eNAM transaction data flows back to enrich the farmer's registry profile.
AgriStack → NPSS (National Pest Surveillance System): When an outbreak is detected, NPSS uses AgriStack's spatial data to identify all farmers within a radius who are growing the affected crop. Targeted advisories go out to exactly the right people.
AgriStack → PM-KISAN / PMFBY: FrUID is the common key. Scheme eligibility verification, beneficiary deduplication, and payment routing all use the Farmer Registry as the source of truth. The ₹2.65 billion savings from removing 21 million ineligible PM-KISAN beneficiaries happened primarily because of Aadhaar-seeded registry deduplication, AgriStack takes this further.
All these integrations use LGD codes (Local Government Directory) for all geographic entities and a unified Crop ID namespace across ICAR, FAO, and AgriStack taxonomies, which means your schema doesn't need custom mapping layers for each system.
Things That Don't Work Yet (Be Honest With Your Roadmap)
AgriStack is live and scaling fast, but some things are still being built out:
Geo-referenced maps are incomplete. Many states have village-level maps, not plot-level polygons yet. Plot-level mapping is a mandatory requirement before DCS can be run, but progress varies by state. Odisha and Madhya Pradesh are ahead; others are still catching up.
Tenant farmers are not yet in the system. The registry is built around land ownership records (RoR). If a farmer leases land and doesn't own it, they're invisible to the system. A "Cultivator Registry" separate from the Owner Registry is planned for Phase 2, but isn't live yet. If your use case involves tenant farmers, which is a large portion of actual cultivators in many states plan for this gap.
Surveyor capacity is stretched. At 1 surveyor per 500 plots nationally, you need roughly 500,000 surveyors. Currently about 250,000 are deployed (Krishi Sakhis, FPO staff, CSC operators, trained youth). The DCS scale is impressive, 28.5 crore plots in a single season - but data freshness depends on surveyor coverage.
Connectivity is still an issue in many areas. The DCS apps are offline-first with local SQLite storage and background sync, but your platform also needs to design for offline scenarios if you're working with farmers in low-connectivity zones.
What You Cannot Do (The Rules Are Non-Negotiable)
Before your legal and compliance team asks, here are the hard limits under DPDP Act 2023 and AgriStack's governance policy:
You cannot resell raw registry data. The data accessed via UFSI stays within your consented use case. You cannot download it and sell it as a data product.
You need consent for every use. There is no "one-time KYC and done." Each data access is tied to a specific purpose and time window.
Aggregated analytics require anonymization. If you're building intelligence products from AgriStack data, the dataset must be k-anonymous with k ≥ 50 (ideally k ≥ 100). No PII in licensed datasets.
State approval matters. Agriculture is a State Subject under the Constitution. Commercial use of state registry data may require state-level MoUs beyond your central UFSI credentials.
Audit logs are mandatory. You must maintain immutable logs of every API call and every consent artefact for 7 years.
Your Go-to-Market Roadmap
Phase 1 — Sandbox and Pilot (Months 0–6)
Register on the AgriStack Developer Portal
Pick a narrow, specific use case (e.g., "KCC pre-qualification for paddy farmers in Eastern UP")
Build your sandbox integration and pass the security audit
Run a pilot with one FPO or 500 farmers
Measure: CAC, conversion rate, farmer NPS, scheme activation rate
Get your UFSI Compliance Badge
Phase 2 — State Launch (Months 6–18)
Partner with one or two progressive states (Odisha, Maharashtra, UP, and MP have strong AgriStack implementation)
Integrate with the State's Digital Farmer Services platform
Onboard 10,000–50,000 farmers through Krishi Sakhis, CSCs, and farmer camps
Demonstrate scheme convergence: show that a farmer using your platform gets KCC + PMFBY + input delivery + advisory all in one place
Build for local language and tenant farmer scenarios
Phase 3 — National Scale (Months 18–36)
FrUID is portable across states, a farmer registered in Odisha can use your platform in UP
Activate cross-scheme data flows with consent
Launch adjacent products: carbon credits, fintech, marketplace
Contribute anonymized intelligence back to the ecosystem (with ethics board approval)
Target: 1 million+ farmers, ₹100 crore+ ARR, profitable unit economics
For CTOs and Architects: Key Technical Decisions
A few decisions early in your architecture will save significant pain later:
Use FrUID as your primary farmer key, not phone number or Aadhaar. FrUID is the only identifier that's both portable across states and linked to verified land and crop records. Phone numbers change, Aadhaar can't be stored without compliance overhead. FrUID is designed for exactly this purpose.
Cache plot geometry aggressively. Plot polygons rarely change (only on land mutation/partition). Cache them in Redis with a 7-day TTL. This keeps you well within rate limits during peak season when you'll have millions of booking/advisory requests hitting your platform simultaneously.
Implement the full consent lifecycle, not just the happy path. You need to handle consent revocation gracefully — when a farmer revokes, your system must immediately stop using that farmer's data and purge it from any short-TTL caches. Build this from Day 1, not as an afterthought.
Design for peak agricultural calendar loads. Your UFSI integration will see very different traffic patterns from software-as-usual. Kharif sowing (June–July) and harvest/procurement (October, April) are peak periods where request volumes can be 10–15x steady state. Pre-warm caches and scale infrastructure before these windows.
Run matching algorithms asynchronously. If you're doing terrain-machinery matching or demand aggregation, don't run these in the API request path. Use a job queue (Celery, RQ, or similar) and push results via WebSocket or push notification. The geospatial compute is too heavy for synchronous requests.
Final Word
AgriStack is the most consequential digital infrastructure project in Indian agriculture since the Green Revolution and that's not an exaggeration.
The numbers make the case: 8.48 crore verified farmer identities, 28.5 crore plot-level crop records, ₹2,817 crore in Digital Agriculture Mission funding, and an Economic Survey projection of 1,000+ viable agritech startups enabled by this infrastructure.
The 2025–26 window is decisive. The infrastructure is live. The early movers who architect natively for AgriStack, who treat FrUID as their primary key, build consent-first UX, and design for the agricultural calendar are going to build the category-defining companies in Indian agritech.
Build on the rails, not around them.
This article was researched and written by the ProdCX team based on government documentation, parliamentary records, World Bank research, MicroSave Consulting analyses, and state implementation handbooks current as of June 2026. For questions or to discuss your AgriStack integration strategy, reach out to us at www.prodcx.com.



Comments