POs in as events. Settlements in as files.
A FilFlo-operated middleware listens for Blinkit events and feeds them into one order trail — and when it's settlement time, a single PRN export produces the credit notes in bulk.
Blinkit raises a purchase order
A PO is issued on the platform against your entity — header, lines, buyer details and delivery location, in Blinkit's own item codes.
FilFlo's middleware picks up the event
A dedicated webhook service — built, run and monitored by FilFlo — ingests platform events as they arrive and forwards them into FilFlo. It is FilFlo-operated infrastructure, not a Blinkit product.
The PO lands mapped and ready to approve
The buyer entity, GSTIN and delivery location resolve to the right customer record, and Blinkit item codes map to your SKUs. The PO enters the approval queue with header and lines intact.
GRN data joins the same order trail
Received and accepted quantities are captured against the same order, so invoice-vs-GRN variance can be classified with reasons instead of hunting across portals.
Export the PRN from the Blinkit portal
The settlement (PRN) file is downloaded from the seller portal — the same export finance already works from.
Import it into FilFlo
The file is consumed as-is. No re-keying line by line, no reformatting before upload.
Bulk credit notes are generated
FilFlo creates one credit note per merchant invoice ID in the PRN export, matched back to the invoices already on the order trail.
Finance closes the settlement gap
The credit notes join the reconciliation-ready event trail alongside the PO, approval, invoice and GRN — and flow into ERP export formats from there.
One PRN export in. One credit note per merchant invoice ID out.
Settlement files are where Blinkit money quietly leaks. FilFlo consumes the PRN export from the portal and generates credit notes in bulk — one per merchant invoice ID — matched back to the invoices already on the order trail, so finance isn't keying credit notes by hand against a spreadsheet. The flow is designed to reduce manual matching and surface exceptions earlier, and the same trail feeds ERP export formats downstream.
What crosses the wire.
Ingested through the FilFlo-operated webhook middleware as events arrive, with file import as the fallback path.
Received and accepted quantities captured against the order, feeding invoice-vs-GRN variance classification with reasons.
Exported from the Blinkit portal and imported into FilFlo, where they generate bulk credit notes — one per merchant invoice ID.
Blinkit buying entities are mapped to FilFlo customer records, so every PO invoices against the right GSTIN and delivery location.
Blinkit item codes are mapped to your SKUs, so lines arrive in your language rather than the platform's.
Invoices, credit notes and other documents go back to Blinkit via the portal or file upload where applicable — there is no outbound API push.
What the workflow enforces — and what it expects.
FilFlo operates the middleware
The webhook service is built, run and monitored by FilFlo, and is in production across multiple FilFlo customers. It is not a Blinkit product, and no Blinkit endorsement is implied.
Production-hardened retries
Event delivery is retried on transient failures — retry behaviour hardened through production use, designed so a delivery hiccup doesn't silently lose a PO.
File-import fallback
When events are unavailable, POs and settlement data can be brought in by file import — the workflow degrades gracefully instead of stopping.
Not an official Blinkit integration
FilFlo operates the middleware independently; Blinkit does not build, maintain or endorse it. If the platform changes how it exposes events, FilFlo updates the middleware on its side.
Outbound is portal and file, not API
Documents going back to Blinkit are submitted through the portal or by file upload where applicable. There is no outbound API connection to the platform.
Settlement runs on file import
PRN files are exported from the portal and imported into FilFlo — credit-note generation runs when a file is imported, not continuously in the background.
Frequently asked questions.
How do Blinkit POs arrive in FilFlo?
Through a dedicated webhook service that FilFlo builds and operates. It ingests platform events as they arrive — PO header and lines, buyer entity, GSTIN and delivery location — and forwards them into FilFlo, where item-code mapping resolves Blinkit codes to your SKUs and the PO enters the approval queue. The workflow is event-driven with a file-import fallback, and its retry behaviour has been hardened in production across multiple customers.
What happens to Blinkit settlement (PRN) files?
They become credit notes in bulk. Export the PRN file from the Blinkit portal, import it into FilFlo, and FilFlo generates one credit note per merchant invoice ID in the export — matched back to the invoices already on the order trail, instead of finance keying each credit note by hand. Full deduction classification and payment reconciliation are on the roadmap — ask us for current status.
Is this an official Blinkit integration?
No — and we say so deliberately. The webhook middleware is built and operated by FilFlo, not by Blinkit, and Blinkit does not sponsor, maintain or endorse it. What we can say honestly: it is a production workflow running for multiple FilFlo customers, with a file-import fallback for when events are unavailable.
What happens if an event fails to deliver?
It is retried. The middleware's retry behaviour has been production-hardened, so transient delivery failures are retried rather than dropped. If events are unavailable for longer, the same POs and settlement data can be brought in by file import — the fallback path uses the same mapping and lands in the same order trail.
Watch a Blinkit PO land, get approved, and settle clean.
Book a 30-minute demo and see the full loop: a PO arriving as an event, SKU-level approval, GST invoicing and GRN variance on one trail — and a PRN export turning into bulk credit notes, one per merchant invoice ID.