DataFlag - Verification Infrastructure
Building the infrastructure layer for digital trust.
A developer-focused infrastructure platform bringing identity, business, vehicle and compliance verification into a unified API ecosystem.
- Industry
- B2B SaaS · Developer Platform
- Services
- Product EngineeringData ServicesAutomationDigital Transformation
- Platform
- Web Platform · REST API · Backend
- Technology
- Next.js · Golang · PostgreSQL · Redis
DataFlag is a verification infrastructure platform. It gives businesses a single API ecosystem for the identity, business, vehicle and compliance checks that sit at the start of almost every regulated digital workflow: onboarding a customer, approving a merchant, verifying a driver before they carry a load.
Individually, those checks are not new. The difficulty is that each one traditionally arrives with its own contract, its own credentials, its own request format and its own failure behaviour. A team that needs six checks ends up integrating six systems and maintaining the differences between them indefinitely.
KwikTech engineered DataFlag as the layer that removes that work: a Golang API platform backed by PostgreSQL and Redis, and a Next.js web and developer experience on top of it. The product is the interface: consistent request and response shapes, one set of credentials, and predictable behaviour across every verification category.
The challenge
Verification sources are not uniform. They differ in how they are addressed, what they return, how quickly they respond and how they behave when they are unavailable. Exposing that variation to customers would have defeated the purpose of the platform. A unified API that is only unified on the surface still leaves every integrator handling special cases.
The platform also had to serve two audiences whose needs pull in different directions. Developers want stable contracts, clear documentation and somewhere safe to test. The businesses paying for those integrations want visibility, auditability and confidence that verification results can withstand scrutiny.
Heterogeneous upstream sources
Each verification category behaves differently. That variation had to be absorbed by the platform rather than passed on to integrators.
Latency as a product requirement
Verification sits inside live onboarding flows. A slow check is a user abandoning a signup, so response time is a feature, not an implementation detail.
Consistency across a growing catalogue
Every new endpoint had to feel like the ones already shipped, or the promise of a single unified contract erodes with each addition.
Two audiences, one product
The same system had to satisfy engineers integrating it and the operations teams accountable for what it returns.
The approach
We treated the API contract as the product and designed it first. Before implementation, we settled how a verification request is expressed, what a successful response looks like, how failure is represented, and how those shapes stay consistent as the catalogue grows across identity, business, vehicle and compliance.
That decision set the architecture. Golang was chosen for the API layer because verification traffic is concurrent, I/O-bound work against external sources, the workload it handles well. PostgreSQL holds structured, relational verification and account data where correctness and auditability matter. Redis serves the fast-access paths where repeating an expensive upstream call adds latency without adding information.
The Next.js frontend was built as the platform's public and developer surface: product documentation, the developer experience, and the marketing site, all served from the same static-first codebase and all talking to the same Golang APIs a customer would integrate against.
What we delivered
A verification platform organised into four public categories (Identity, Business, Vehicle and Compliance), exposed through one REST interface, one authentication model and one dashboard.
Every endpoint follows the same conventions: a JSON request, a bearer-token header, a structured JSON response, and the same error semantics regardless of which upstream source served it. A developer who integrates one endpoint has effectively learned the rest.
Identity verification
PAN, Aadhaar linkage and Voter ID checks against authoritative registry records.
Business verification
GST, MSME, Udyam and company information lookups for verifying the entity behind a transaction.
Vehicle verification
Registration certificate, engine and chassis, driving licence and challan lookups.
Compliance workflows
Compliance status and audit-ready verification logs supporting KYC and onboarding processes.
How the platform is put together.
Verification request path
A customer's application talks to one API layer. That layer resolves the request, reads and writes structured data in PostgreSQL, and uses Redis for the fast-access paths, so the calling application never deals with the variation behind it.
- Client
Business Application
Onboarding, KYC or approval flow calling the API
- Platform
DataFlag API Layer
Golang
Authentication, routing and verification orchestration
- Data
PostgreSQL
Verification records, accounts and usage data
Redis
Caching and fast-access data paths
Web and developer platform
The public site, product documentation and developer experience are one Next.js application, consuming the same APIs that customers integrate against.
- Surface
Web & Developer Platform
Next.js
Product site, documentation and developer experience
- Platform
DataFlag APIs
Golang
The same REST interface customers integrate against
One contract, whichever check you call.
POST /v1/vehicle/dl/verify HTTP/1.1
Host: api.dataflag.in
Authorization: Bearer $API_KEY
Content-Type: application/json
{
"dl_number": "XX00XXXXXXXXXXX",
"date_of_birth": "1990-01-01"
}Every endpoint takes a JSON body and a bearer token. The shape does not change between verification categories.
HTTP/1.1 200 OK
{
"status": "success",
"latency_ms": 214,
"data": {
"valid": true,
"name": "<redacted>",
"issuing_authority": "<redacted>",
"validity": {
"from": "2019-04-12",
"to": "2039-04-11"
},
"vehicle_classes": ["LMV", "MCWG"]
}
}Structured, predictable responses. Personal fields are redacted in this example, because the platform never exposes credentials or customer data in documentation.
Unified API contract
One request and response shape across every verification category, so integration effort does not multiply with each endpoint adopted.
Golang API platform
A concurrent backend built for high-volume, I/O-bound verification traffic against external sources.
Structured relational data
PostgreSQL models verification records, accounts and usage where relational integrity and auditability matter.
Redis caching layer
Fast-access data paths that keep response times low without repeating unnecessary upstream work.
Developer experience
Documentation, quickstart guides and a sandbox environment returning real response shapes against no live data.
Single-key access model
One contract, one dashboard and one credential across the whole catalogue, rather than per-source onboarding.
Next.js web platform
The product, documentation and developer surfaces built as one fast, statically-rendered frontend.
Audit-ready logging
Verification activity recorded so compliance teams can evidence what was checked and when.
The developer platform, dashboard and verification catalogue as they appear in the live product.
The public platform site
The verification API catalog
In-console request testing against a demo account
- A single integration surface replacing separate per-source contracts and credentials
- Consistent request and response semantics across every verification category
- A sandbox environment allowing teams to build against real response shapes before going live
- An API catalogue that can grow without changing how existing integrations work
- Verification activity captured for compliance and audit review
The capabilities behind this work.
Building API infrastructure?
If you're designing a platform other engineering teams will build on, the API contract is the product. Let's talk about getting it right.