{"id":24297,"date":"2026-09-15T05:56:43","date_gmt":"2026-09-15T05:56:43","guid":{"rendered":"https:\/\/engineerbabu.com\/blog\/?p=24297"},"modified":"2026-09-15T05:56:43","modified_gmt":"2026-09-15T05:56:43","slug":"how-to-build-an-app-like-zepto","status":"publish","type":"post","link":"https:\/\/engineerbabu.com\/blog\/how-to-build-an-app-like-zepto\/","title":{"rendered":"How to Build an App Like Zepto?"},"content":{"rendered":"<p><b>TL;DR<\/b><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Zepto&#8217;s ten minutes comes from a store sitting 2 km away, not from a faster app.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">You are shipping four connected products: customer app, picker app, rider app, and an ops console.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">A serious MVP to build an app like Zepto runs about $75,000 to $145,000 over 4 to 6 months.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Margins live or die on batching, stockouts, and forecasting, so budget for those before UI polish.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Ten minutes is not a delivery promise. It is a real estate decision made months before a customer ever taps &#8220;order.&#8221;<\/span><\/p>\n<p><span style=\"font-weight: 400;\">That is the part most founders miss. If you want to build an app like Zepto, the checkout screen is the easy half. The hard half is software that picks the right dark store, sequences the picker, batches the rider, and keeps a live inventory ledger honest down to the last packet of bread.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This guide covers the model, the architecture, the stack, realistic costs, and the steps in order, whether you <\/span><a href=\"https:\/\/engineerbabu.com\/blog\/build-an-app-like-blinkit\/\"><span style=\"font-weight: 400;\">build an app like Blinkit<\/span><\/a><span style=\"font-weight: 400;\">, Zepto, or a narrower version of either.<\/span><\/p>\n<h2><b>Is quick commerce still worth entering in 2026?<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Yes, but only with a narrow starting market and tight unit economics.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The category is still expanding fast. India&#8217;s quick commerce market grew at a 71.2% CAGR between 2020 and 2024, and is forecast to keep compounding at 17.6% through 2029, when it should reach $12.97 billion (<\/span><a href=\"https:\/\/www.globenewswire.com\/news-release\/2026\/04\/20\/3277255\/28124\/en\/india-quick-commerce-report-2026-market-to-reach-12-97-billion-by-2029-blinkit-zepto-and-swiggy-instamart-lead-surge-as-jiomart-and-bigbasket-scale-competitive-entry.html\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">ResearchAndMarkets via GlobeNewswire<\/span><\/a><span style=\"font-weight: 400;\">).<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Three incumbents already hold most urban GMV. So teams that build an app like Zepto today win on focus, not coverage: one city, one category, one underserved cluster of pin codes. Pharmacy, pet supplies, beauty, and restaurant supply are all live examples of that narrower play.<\/span><\/p>\n<h2><b>What Zepto actually sells<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Speed is the product. Everything else in the business exists to protect it.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Store spacing is your delivery time<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">A dark store is a closed retail space of 1,500 to 3,000 sq ft holding 2,000 to 5,000 fast-moving SKUs. It serves a radius of roughly 2 to 3 km.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">At that distance, a rider covers the trip in six to eight minutes. That leaves two to three minutes for picking and handover. Change the radius and you change the promise. Anyone planning to build an app like Zepto should map store coverage polygons before writing product code.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Assortment beats catalog size<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Zepto does not try to stock a supermarket. It stocks what a neighborhood reorders every week.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A tight assortment raises pick speed, cuts dead stock, and protects availability. Availability is the metric customers actually feel, which is why teams that build an app like Zepto watch it daily. An out-of-stock item at checkout costs you the order and the habit behind it.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Picking is the bottleneck, not riding<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Most teams optimize routing first. Real dark store data points the other way.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A picker gets 90 to 120 seconds to assemble a basket, scan it, and stage it at the handover rack. Shelf mapping, pick sequencing, and barcode scanning move that number far more than any map API will. Solve picking early when you build an app like Zepto.<\/span><\/p>\n<h2><b>The four apps you need<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Every serious attempt to build an app like Zepto ends up as four interfaces sitting on one shared order state.<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>App<\/b><\/td>\n<td><b>Primary user<\/b><\/td>\n<td><b>Must-have capability<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Customer app<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Buyer<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Serviceability check, store-level live stock, substitutions, live ETA<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Picker app<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Dark store staff<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Pick list by shelf sequence, barcode scan, stock-out flagging<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Rider app<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Delivery partner<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Batched queue, navigation, OTP proof of delivery, earnings<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Ops console<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Central and store managers<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Inventory, pricing, demand heatmaps, SLA and refund control<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span style=\"font-weight: 400;\">The customer app is where founders overspend. Keep it fast and boring. Solid<\/span><a href=\"https:\/\/engineerbabu.com\/services\/mobile-app-development\"> <span style=\"font-weight: 400;\">mobile app development<\/span><\/a><span style=\"font-weight: 400;\"> matters here mostly for cold start time, search speed, and cart reliability on weak networks.<\/span><\/p>\n<h2><b>Three systems that decide whether you survive<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Features get you launched. These three systems decide whether you last past month six when you build an app like Zepto.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>A single real-time inventory ledger<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Stock must be tracked per store, not per catalog. Every pick, cancellation, and return has to write back within seconds.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This is an integration problem more than a UI problem. Careful<\/span><a href=\"https:\/\/engineerbabu.com\/services\/api-development\"> <span style=\"font-weight: 400;\">API development<\/span><\/a><span style=\"font-weight: 400;\"> across your POS, warehouse receipts, payment provider, and customer app prevents the worst failure in quick commerce: selling something the shelf does not have.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>A dispatch engine that batches intelligently<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Your dispatcher decides which rider takes which order, and whether two nearby orders ride together.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Batch too hard and delivery times slip. Batch too little and cost per order climbs. Teams that build an app like Zepto usually start with rule-based assignment, then move to<\/span><a href=\"https:\/\/engineerbabu.com\/technologies\/machine-learning-development-services\"> <span style=\"font-weight: 400;\">ML development<\/span><\/a><span style=\"font-weight: 400;\"> for ETA prediction and rider matching once they hold three months of trip data.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Demand forecasting per store, per hour<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Each dark store needs its own replenishment plan. Rain, salary day, cricket fixtures, and festivals all move basket composition.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Forecasting with<\/span><a href=\"https:\/\/engineerbabu.com\/services\/ai-development\"> <span style=\"font-weight: 400;\">AI development<\/span><\/a><span style=\"font-weight: 400;\"> turns that into an ordering schedule, so fast movers stay stocked and perishables do not rot. Good forecasts raise availability and cut wastage at the same time, which is rare. Skip this and you build an app like Zepto that over-orders perishables every week.<\/span><\/p>\n<h2><b>Tech stack for a quick commerce app<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Nothing exotic here, and that is the point. Whatever stack you choose to build an app like Zepto gets punished every evening at peak hour.<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Mobile<\/b><span style=\"font-weight: 400;\">: <\/span><a href=\"https:\/\/engineerbabu.com\/technologies\/flutter-development-services\"><span style=\"font-weight: 400;\">Flutter<\/span><\/a><span style=\"font-weight: 400;\"> or React Native for speed to market, native Kotlin and Swift once scale justifies it<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Backend<\/b><span style=\"font-weight: 400;\">: Node.js or Go microservices for orders, inventory, dispatch, and payments<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Data<\/b><span style=\"font-weight: 400;\">: PostgreSQL with PostGIS for geospatial zones, Redis for stock reservations and hot carts<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Events<\/b><span style=\"font-weight: 400;\">: Kafka or SQS so order, pick, and dispatch events stay decoupled<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Realtime<\/b><span style=\"font-weight: 400;\">: WebSockets or MQTT for live tracking and rider location pings<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Infra<\/b><span style=\"font-weight: 400;\">: AWS or GCP with autoscaling, since evening peaks run several times the daily average<\/span><\/li>\n<\/ul>\n<h2><b>How to build an app like Zepto, step by step<\/b><\/h2>\n<h3><b>Step 1: Pick one micro market and validate it<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Choose a 3 km cluster with high order density, not a whole city. Validate with a rented store, a short SKU list, and a manual dispatcher working off a spreadsheet.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Run that for three weeks. You are measuring repeat rate, basket value, and how often you stock out. A focused<\/span><a href=\"https:\/\/engineerbabu.com\/services\/mvp-development\"> <span style=\"font-weight: 400;\">MVP development<\/span><\/a><span style=\"font-weight: 400;\"> approach turns those numbers into product requirements. Validation belongs before you build an app like Zepto, not after the first release ships.<\/span><\/p>\n<h3><b>Step 2: Model the catalog and inventory first<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Before any screen gets designed, define SKU structure, unit of measure, batch and expiry handling, and store-level stock. Decide how substitutions and partial fulfilments behave.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This data model is the spine of the platform. Getting it wrong forces rewrites in pricing, promotions, refunds, and reporting later.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Every team that goes on to build an app like Zepto successfully locks this layer early. Map each SKU to a shelf location too, since that mapping makes the picker app fast on day one.<\/span><\/p>\n<h3><b>Step 3: Build the customer app around intent, not browsing<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Quick commerce buyers arrive knowing what they want. Median session length sits under two minutes, so build an app like Zepto around reordering rather than discovery.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">So the home screen should surface reorders, recent items, and top categories first. Serviceability has to resolve before the catalog renders, otherwise customers see items they cannot buy. Search needs typo tolerance and local language handling. Keep checkout to one screen with a saved address and a default payment method.<\/span><\/p>\n<h3><b>Step 4: Ship the picker and rider apps with the store team watching<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Build these two inside a live dark store, not from a design file. Sit with pickers for a week before you finalize anything.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">You will learn that they work one-handed, in cold aisles, in a hurry. Large tap targets, offline tolerance, and audible scan confirmation beat visual polish here. These two apps quietly set your operating cost when you build an app like Zepto, because a dead rider phone means a lost order.<\/span><\/p>\n<h3><b>Step 5: Wire payments, refunds, and instant cancellations<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Support UPI, cards, wallets, netbanking, and cash on delivery from launch. Reserve stock at payment initiation and release it if the payment fails.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Refunds are the trust moment in quick commerce. Missing item, damaged item, and late delivery each need an automated resolution path.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Teams borrowing patterns from<\/span><a href=\"https:\/\/engineerbabu.com\/industries\/fintech\/app-development-company\"> <span style=\"font-weight: 400;\">fintech app development<\/span><\/a><span style=\"font-weight: 400;\"> handle reconciliation and chargebacks far more cleanly than teams inventing it from scratch.<\/span><\/p>\n<h3><b>Step 6: Launch one store, instrument everything, then clone<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Go live with a single dark store and a hard cap on daily orders. Track pick time, handover time, ride time, availability rate, and cost per order every single day.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Open store two only when store one holds its SLA and a stable contribution margin. The cheapest way to build an app like Zepto is to get store one boringly right, because quick commerce scales by replication. Any process you have not documented becomes a defect you copy ten times.<\/span><\/p>\n<h2><b>What it costs to build an app like Zepto<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Software is the smaller line item when you build an app like Zepto. Stores, inventory, and rider supply cost more.<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Workstream<\/b><\/td>\n<td><b>Estimated cost<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Discovery, UX, and architecture<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$6,000 to $12,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Customer <\/span><a href=\"https:\/\/engineerbabu.com\/industries\/on-demand\/app-development-company\"><span style=\"font-weight: 400;\">On demand app<\/span><\/a><span style=\"font-weight: 400;\"> (iOS and Android)<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$18,000 to $35,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Picker and rider apps<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$15,000 to $28,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Backend, inventory, and dispatch services<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$20,000 to $40,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Ops console and analytics<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$8,000 to $15,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">QA, launch, and 3 months of support<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$8,000 to $15,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><b>MVP total<\/b><\/td>\n<td><b>$75,000 to $145,000<\/b><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span style=\"font-weight: 400;\">Add 15 to 20% of build cost per year for maintenance. Then add third party costs for maps, SMS, payment fees, and cloud, which scale with orders rather than with code.<\/span><\/p>\n<h2><b>Mistakes that quietly kill these apps<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Most teams that fail to build an app like Zepto profitably lose on one of these five.<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Treating inventory as eventually consistent.<\/b><span style=\"font-weight: 400;\"> Stale stock creates cancellations, and cancellations create churn.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Batching by distance only.<\/b><span style=\"font-weight: 400;\"> Item count, pick time, and perishability all belong in the batching logic.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Launching city-wide.<\/b><span style=\"font-weight: 400;\"> Density wins. Coverage without density burns cash on idle riders.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>No substitution flow.<\/b><span style=\"font-weight: 400;\"> One out-of-stock item should never kill an entire cart.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Ignoring rider experience.<\/b><span style=\"font-weight: 400;\"> Rider churn raises delivery cost faster than marketing lowers acquisition cost.<\/span><\/li>\n<\/ul>\n<h2><b>Where EngineerBabu fits<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">EngineerBabu helps founders build an app like Zepto end to end, from dark store operations software to consumer apps that hold up under real peak load.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If you are still comparing vendors, our breakdown of the<\/span><a href=\"https:\/\/engineerbabu.com\/blog\/mobile-app-development-companies-in-the-usa\/\"> <span style=\"font-weight: 400;\">top mobile app development companies<\/span><\/a><span style=\"font-weight: 400;\"> works as a shortlisting checklist.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The work spans product architecture, mobile, backend, dispatch logic, and the AI layer for forecasting, delivered on a CMMI Level 5 process with senior engineers who stay on the project.<\/span><\/p>\n<p><b>About EngineerBabu<\/b><\/p>\n<p><a href=\"http:\/\/engineerbabu.com\"><span style=\"font-weight: 400;\">EngineerBabu<\/span><\/a><span style=\"font-weight: 400;\"> is a technology development company building products across fintech, healthtech, and AI, from MVPs to scaled, production-ready platforms. It holds a CMMI Level 5 rating, has worked with 4 unicorn clients, and has supported 200+ VC-funded products. The company is backed by Vijay Shekhar Sharma.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Founded by Mayank Pratap (Co-founder) \u00b7 mayank@engineerbabu.com<\/span><\/p>\n<h2><b>FAQs<\/b><\/h2>\n<ul>\n<li aria-level=\"1\">\n<h3><b>How long does it take to build an app like Zepto?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">A launch-ready MVP with all four apps takes 4 to 6 months with a team of eight to ten people. Add two to three months if you need custom forecasting, multi-city zones, or deep ERP integration from day one.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>How much does it cost to build an app like Zepto?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Software runs roughly $75,000 to $145,000 for an MVP. Dark store leases, inventory, rider payouts, and customer acquisition usually cost more than the software during your first year of operation.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Can I launch with fewer than four apps?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Yes, briefly. Some teams run picking through a tablet-based web console at first. You still need separate customer and rider apps, since their permissions, session lengths, and offline behavior have almost nothing in common.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>How many dark stores do I need to start?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">One. Prove pick time, availability, and cost per order in a single 2 to 3 km zone first. Most failed quick commerce startups opened ten stores before store one was actually profitable.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Is 10-minute delivery realistic outside metro cities?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Often not. In lower density areas, a 20 to 30 minute promise with better availability and pricing usually wins. Set the SLA your store spacing can actually support, then hold it consistently.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>TL;DR Zepto&#8217;s ten minutes comes from a store sitting 2 km away, not from a faster app. You are shipping four connected products: customer app, picker app, rider app, and an ops console. A serious MVP to build an app like Zepto runs about $75,000 to $145,000 over 4 to 6 months. Margins live or [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":24298,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1258],"tags":[],"class_list":["post-24297","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-app-development"],"_links":{"self":[{"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/posts\/24297","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/comments?post=24297"}],"version-history":[{"count":1,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/posts\/24297\/revisions"}],"predecessor-version":[{"id":24299,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/posts\/24297\/revisions\/24299"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/media\/24298"}],"wp:attachment":[{"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/media?parent=24297"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/categories?post=24297"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/tags?post=24297"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}