{"id":15473,"date":"2026-06-01T11:30:51","date_gmt":"2026-06-01T06:00:51","guid":{"rendered":"http:\/\/10.10.164.133\/?p=15473"},"modified":"2026-06-01T13:28:22","modified_gmt":"2026-06-01T07:58:22","slug":"prodcast","status":"publish","type":"post","link":"https:\/\/payu.in\/blog\/prodcast\/","title":{"rendered":"ProdCast"},"content":{"rendered":"\n

Production tells the truth.<\/strong>
Code states the intent.<\/strong>
Record-replay bridges<\/s> proves them<\/mark>.<\/strong><\/p>\n\n\n\n

AI coding agents have made our team meaningfully faster. They have also introduced a category of bugs we didn\u2019t have at the same rate before: changes that look correct, pass review, and quietly break a flow nobody re-tested because nobody knew it was at risk \u2014 context the agent didn\u2019t have, an assumption that didn\u2019t hold, a fix that solved the prompt instead of the bug. We built ProdCast as the safety net underneath all of it: a regression suite built on real production traffic, replayed against new code before it ships, that proves the changes only do what they\u2019re supposed to do.<\/em><\/p>\n\n\n\n

Why we built this<\/strong><\/h2>\n\n\n\n

Our team adopted AI coding agents the way most teams have: cautiously at first, then quickly, once it became clear how much faster routine work could ship. The productivity gains were real. So were the edge cases.<\/p>\n\n\n\n

The pattern wasn\u2019t agents producing obviously broken code \u2014 review catches that. It was subtler: a routing rule fixed for the bug it was asked about, unintentionally altering three other flows that depended on the same rule. A refactor passing every test it was asked to write, because the tests only covered the path it changed. A fix that worked perfectly in isolation and silently regressed a downstream service nobody had thought to check. The common thread is that the agent only knew what it was shown<\/strong> \u2014 when the context window missed something, when an assumption didn\u2019t hold, when the prompt was narrow, the fix was narrow too, and the existing flows around it absorbed the damage quietly.<\/p>\n\n\n\n

Our team\u2019s response wasn\u2019t to slow the agents down. It was to build a regression layer that didn\u2019t rely on someone remembering to test every flow the agent might have touched. ProdCast<\/strong> is that layer. It takes real production traffic \u2014 the actual requests, with the actual state, against the actual downstream contracts \u2014 and replays it against the new code before deploy. If a flow the agent shouldn\u2019t have changed has changed, the replay surfaces it.<\/p>\n\n\n\n

Tests verify what you changed. ProdCast verifies what you didn\u2019t.<\/strong><\/em><\/p>\n\n\n\n

In short:<\/strong> ProdCast records what production actually does, replays the same request against a proposed code change on a local cluster, and tells you whether the behavior is identical or has drifted. Teams use it to ship faster \u2014 every PR comes with evidence that nothing it shouldn\u2019t have changed has changed.<\/p>\n\n\n\n

So what does \u201creplays real production traffic\u201d<\/em> actually mean in practice? The harness is a seven-phase pipeline \u2014 capture, rebuild state, replay, compare, explain \u2014 with two optional setup phases and the rest required. Walked through next.<\/p>\n\n\n\n

The pipeline<\/strong><\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Seven phases across two tracks. The production track and local track draw on two shared inputs \u2014 Request Bodies and LogFilterRules \u2014 converge at the compare step, and feed into the MCP-backed Why Layer for diagnosis.<\/sub><\/em><\/p>\n\n\n\n

The diagram above shows seven phases organized into two parallel tracks, a convergence, and an explanation. What it doesn\u2019t show is what holds them together: two shared pieces \u2014 Request Bodies<\/strong> and LogFilterRules<\/strong> \u2014 that guarantee both tracks are answering the same question and reading the answer the same way.<\/p>\n\n\n\n

Production track<\/strong><\/h2>\n\n\n\n

Record from production<\/strong><\/p>\n\n\n\n

Goal. <\/strong>Capture the canonical response and the telemetry that surrounded it.<\/p>\n\n\n\n

How. <\/strong>POST the predefined request body to the production endpoint, save the response, then query the log store for every line tagged with the returned trace ID within a small window of the recorded timestamp.<\/p>\n\n\n\n

Note. <\/strong>This is where the correlation key is born. Without a clean trace ID on the response, none of the later phases can line up the two sides of the diff.<\/p>\n\n\n\n

\n
\"\"<\/figure>\n<\/figure>\n\n\n\n

Hit production \u00b7 capture response \u00b7 fetch and filter prod logs by trace ID<\/sub><\/em><\/p>\n\n\n\n

Local track<\/strong><\/h2>\n\n\n\n

Sync local tables from production<\/strong><\/p>\n\n\n\n

Goal. <\/strong>Make the local cluster\u2019s database look enough like production\u2019s for the replay to be meaningful.<\/p>\n\n\n\n

How. <\/strong>Pull from a reporting DB, a saved Redash query, or a snapshot file \u2014 whichever the team has standardized on \u2014 and write the relevant tables into local MySQL.<\/p>\n\n\n\n

Skip when. <\/strong>The replay path doesn\u2019t read relational state, or the local DB was synced earlier the same day.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Pull from reference data source \u00b7 write tables into local MySQL<\/sub><\/em><\/p>\n\n\n\n

Warm up the local environment<\/strong><\/p>\n\n\n\n

Goal. <\/strong>Get the local service into a state where the next request won\u2019t fail for cold-start reasons unrelated to the actual diff.<\/p>\n\n\n\n

How. <\/strong>Start the service, hit health endpoints, run any team-standard warm-up calls that prime in-process state, config caches, or JIT-compiled paths.<\/p>\n\n\n\n

Note. <\/strong>Skipping this is the most common cause of a diff that says \u201clocal returned 500\u201d<\/em> \u2014 and 500s break the comparison before it can tell you anything useful.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Start service \u00b7 confirm health \u00b7 warm caches to avoid cold-start 500s<\/sub><\/em><\/p>\n\n\n\n

Sync the local cache (optional)<\/em><\/strong><\/p>\n\n\n\n

Goal. <\/strong>Pre-populate the local Redis with the same shape of state the production cache had when the request was recorded.<\/p>\n\n\n\n

How. <\/strong>Use the filtered prod logs as the source: extract the cache values the service read during the production call, then write them into local Redis under the keys the service expects.<\/p>\n\n\n\n

Skip when. <\/strong>The replay path doesn\u2019t read from cache, or the service under test doesn\u2019t use Redis at all.<\/p>\n\n\n\n

Worth noting. <\/strong>Cache keys for the same entity (a merchant, a tenant, a user) tend to collide across scenarios \u2014 one scenario\u2019s write overwrites another\u2019s. Anyone adopting the harness has to decide upfront how scenarios will be isolated from each other in shared cache space.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Read what prod read \u00b7 write the same shape to local Redis \u00b7 OPTIONAL<\/sub><\/em><\/p>\n\n\n\n

Replay against local<\/strong><\/p>\n\n\n\n

Goal. <\/strong>Run the same predefined request against the local cluster and capture what it returns.<\/p>\n\n\n\n

How. <\/strong>POST the same request body that was sent to production, save the response, tail the service\u2019s console logs into a file, then filter those logs the same way the prod logs were filtered.<\/p>\n\n\n\n

Worth noting. <\/strong>This is the phase where AI-introduced regressions surface. The production track captured what the system did<\/em> on the unchanged code. This replay captures what the system does now<\/em>, with the agent\u2019s changes in place. The comparison step is the only place that difference becomes legible.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Same body as prod \u00b7 local service with new code \u00b7 save response + tail logs<\/sub><\/em><\/p>\n\n\n\n

The convergence<\/strong><\/h2>\n\n\n\n

Compare and report<\/strong><\/p>\n\n\n\n

Goal. <\/strong>Show, with evidence, where production and local diverged.<\/p>\n\n\n\n

How. <\/strong>Deep-diff the two response JSONs, align the two filtered log streams, highlight the fields the team cares about (gateway ID, routing region, pricing tier \u2014 whatever the service\u2019s \u201coutput\u201d<\/em> actually is), and publish an HTML page per scenario plus a summary index.<\/p>\n\n\n\n

What you read first. <\/strong>The verdict (IDENTICAL or DIFFERENT) and the highlighted field diff. Logs are for context. For divergences, the next phase explains why<\/em>.<\/p>\n\n\n\n

The explanation<\/strong><\/h2>\n\n\n\n

The Why Layer<\/strong><\/p>\n\n\n\n

Goal. <\/strong>Take the diff and explain it. Which code changed, why the change shifted the response, and whether the divergence is a regression or expected.<\/p>\n\n\n\n

How. <\/strong>A local MCP server reads both branches involved \u2014 the production deploy branch and the branch being tested locally \u2014 alongside the diff verdict, the diverging fields, and the filtered log streams from both sides. It maps each diverging field back to the code that produces it, identifies the commits between the two branches that touch that code, and reasons about what kind<\/em> of divergence this is using project context: a routing rule that was added on local but not yet merged, a config value that\u2019s only set in production, a cached value that\u2019s stale on local, a downstream contract that one side honors and the other doesn\u2019t. The output isn\u2019t just \u201cX differs from Y\u201d<\/em> \u2014 it\u2019s a short paragraph naming the suspected cause and the file, commit, or config to look at.<\/p>\n\n\n\n

What the engineer reads. <\/strong>Three things, in order. First, the cause classification \u2014 code change<\/em>, missing config<\/em>, stale cache<\/em>, business-logic shift<\/em>, upstream contract drift<\/em>. Second, the attribution \u2014 the specific commit, file, and line that introduced the divergence, with a one-sentence summary of what the commit did. Third, the verdict from project context \u2014 whether the local branch\u2019s behavior or the prod branch\u2019s behavior is the one the team intends to keep, based on the PR description, related issue, or any project-specific rules the MCP has access to.<\/p>\n\n\n\n

Worth noting. <\/strong>The MCP isn\u2019t authoritative. It surfaces the most likely explanation and the evidence supporting it; the engineer still decides what to do with that. In practice, the most useful output isn\u2019t the cause classification \u2014 it\u2019s the \u201clook here first\u201d<\/em> pointer that turns a 30-minute investigation into a 30-second one.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Diff in \u00b7 branches read + context applied \u00b7 structured explanation out<\/sub><\/em><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The Why Layer for one scenario \u2014 diff above, MCP cause classification + code attribution + verdict from PR context below.<\/sub><\/em><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The batch summary after a run \u2014 one row per scenario, with verdict, similarity, and the selected ID compared.<\/sub><\/em><\/p>\n\n\n\n

A note on customer data<\/strong><\/h2>\n\n\n\n

ProdCast is built around a constraint: real customer data never leaves production. Every step that touches prod \u2014 table sync, response capture, cache seeding, the comparison report \u2014 works with masked or synthetic values. If the harness ever needed real PII to do its job, the test wouldn\u2019t be testing behavior anymore.<\/p>\n\n\n\n

Adopting it: what each team configures<\/strong><\/h2>\n\n\n\n

Most of what you just walked through is generic. The OpenSearch queries, the cache-seeding logic, the diff renderer, the report HTML \u2014 none of it changes per service. A team picking ProdCast up for a new service only needs to configure three things:<\/p>\n\n\n\n

    \n
  1. Request Bodies.<\/strong> A set of scenario payloads covering the edge cases the team cares about \u2014 happy paths, known-tricky requests, the merchant that exposed a bug last quarter. Each scenario is a single JSON file; the harness picks them up automatically.<\/li>\n\n\n\n
  2. LogFilterRules.<\/strong> The regex and field-extraction rules that decide which log lines matter for this service. Different services log different things, so this is where service-specific knowledge lives. Once written, the same rules apply to both prod and local sides.<\/li>\n\n\n\n
  3. Endpoints.<\/strong> The production URL the harness hits to record, and the local URL it hits to replay, plus any auth the service requires.<\/li>\n<\/ol>\n\n\n\n
    \"\"<\/figure>\n\n\n\n

    Two shared pieces, four destinations \u2014 the alignment keys for the diff.<\/sub><\/em><\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    The harness in action \u2014 scenarios on the left, pipeline phases as toggles, and the run log streaming on the right.<\/sub><\/em><\/p>\n\n\n\n

    What this changes in practice<\/strong><\/h2>\n\n\n\n

    Before ProdCast, a \u201cproduction behaves differently than my local\u201d<\/em> investigation was a half-day exercise of curl, console.log, and educated guessing. Most of that time was spent rebuilding context \u2014 what was the request, what state did prod have, what does my local actually see \u2014 before any real debugging could start.<\/p>\n\n\n\n

    After ProdCast, that work happens automatically. The engineer runs one command, gets a report in a few minutes, and either confirms parity (move on with confidence) or gets a precise diff with a starting point for the actual bug.<\/p>\n\n\n\n

    The shifts we noticed:<\/p>\n\n\n\n

      \n
    • Bugs get reported with reports.<\/strong> Instead of \u201cthis looks wrong on my branch,\u201d<\/em> PRs come with a ProdCast report attached, showing exactly which scenarios pass and which diverge.<\/li>\n\n\n\n
    • Code review changed shape.<\/strong> A reviewer can ask \u201cdid you run ProdCast on the affected endpoints?\u201d<\/em> and that\u2019s a concrete, verifiable question instead of a vibe.<\/li>\n\n\n\n
    • The question \u201cwhat else might this have broken?\u201d got an answer.<\/strong> Before, it was the kind of question PRs lingered on indefinitely because the team had no concrete way to check. Now ProdCast is the check. PRs move.<\/li>\n<\/ul>\n\n\n\n

      Closing<\/strong><\/h2>\n\n\n\n

      ProdCast isn\u2019t a clever idea. It\u2019s an unglamorous one: capture real traffic, save it, replay it, diff it. The interesting work is in the seams \u2014 getting log ingestion timing right, avoiding shared-key collisions in Redis, parsing logs that change shape every quarter, making the report readable enough that engineers actually open it.<\/p>\n\n\n\n

      Each of those seams was something our team learned the hard way and encoded into the pipeline so the next engineer doesn\u2019t have to. That\u2019s mostly what mature infrastructure tooling is: a record of every avoidable mistake the team has already made once.<\/p>\n\n\n\n

      The mistakes we\u2019re avoiding now belong to a new era. We didn\u2019t slow the agents down to catch them. We added a layer underneath them \u2014 one that uses the only source of truth that doesn\u2019t lie about production behavior: production behavior itself<\/strong>.<\/p>\n\n\n\n

      The bug you\u2019re chasing today is probably one ProdCast report away from being obvious.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

      Production tells the truth.Code states the intent.Record-replay bridges proves them. AI coding agents have made our team meaningfully faster. They have also introduced a category of bugs we didn\u2019t have…<\/p>\n","protected":false},"author":94,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1232],"tags":[],"yoast_head":"\nProdCast - PayU Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/payu.in\/blog\/prodcast\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"ProdCast - PayU Blog\" \/>\n<meta property=\"og:description\" content=\"Production tells the truth.Code states the intent.Record-replay bridges proves them. AI coding agents have made our team meaningfully faster. They have also introduced a category of bugs we didn\u2019t have...\" \/>\n<meta property=\"og:url\" content=\"https:\/\/payu.in\/blog\/prodcast\/\" \/>\n<meta property=\"og:site_name\" content=\"PayU Blog\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/PayUind\/\" \/>\n<meta property=\"article:published_time\" content=\"2026-06-01T06:00:51+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-06-01T07:58:22+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/payu.in\/blog\/wp-content\/uploads\/2026\/06\/00-pipeline-overview.png\" \/>\n<meta name=\"author\" content=\"Dev Pratap Singh\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@payuind\" \/>\n<meta name=\"twitter:site\" content=\"@payuind\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Dev Pratap Singh\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"10 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"http:\/\/10.10.164.133\/prodcast\/\",\"url\":\"http:\/\/10.10.164.133\/prodcast\/\",\"name\":\"ProdCast - PayU Blog\",\"isPartOf\":{\"@id\":\"https:\/\/payu.in\/blog\/#website\"},\"datePublished\":\"2026-06-01T06:00:51+00:00\",\"dateModified\":\"2026-06-01T07:58:22+00:00\",\"author\":{\"@id\":\"https:\/\/payu.in\/blog\/#\/schema\/person\/53f4d6cd68d042768a86e784c4c59294\"},\"breadcrumb\":{\"@id\":\"http:\/\/10.10.164.133\/prodcast\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"http:\/\/10.10.164.133\/prodcast\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"http:\/\/10.10.164.133\/prodcast\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/payu.in\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Engineering Blogs\",\"item\":\"http:\/\/10.10.164.133\/category\/engineering-blogs\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"ProdCast\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/payu.in\/blog\/#website\",\"url\":\"https:\/\/payu.in\/blog\/\",\"name\":\"PayU Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/payu.in\/blog\/?s={search_term_string}\"},\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/payu.in\/blog\/#\/schema\/person\/53f4d6cd68d042768a86e784c4c59294\",\"name\":\"Dev Pratap Singh\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/payu.in\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/a8dea061f69a548552b66d2ebddf2605?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/a8dea061f69a548552b66d2ebddf2605?s=96&d=mm&r=g\",\"caption\":\"Dev Pratap Singh\"},\"url\":\"https:\/\/payu.in\/blog\/author\/dev-singh\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"ProdCast - PayU Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/payu.in\/blog\/prodcast\/","og_locale":"en_US","og_type":"article","og_title":"ProdCast - PayU Blog","og_description":"Production tells the truth.Code states the intent.Record-replay bridges proves them. AI coding agents have made our team meaningfully faster. They have also introduced a category of bugs we didn\u2019t have...","og_url":"https:\/\/payu.in\/blog\/prodcast\/","og_site_name":"PayU Blog","article_publisher":"https:\/\/www.facebook.com\/PayUind\/","article_published_time":"2026-06-01T06:00:51+00:00","article_modified_time":"2026-06-01T07:58:22+00:00","og_image":[{"url":"https:\/\/payu.in\/blog\/wp-content\/uploads\/2026\/06\/00-pipeline-overview.png"}],"author":"Dev Pratap Singh","twitter_card":"summary_large_image","twitter_creator":"@payuind","twitter_site":"@payuind","twitter_misc":{"Written by":"Dev Pratap Singh","Est. reading time":"10 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"http:\/\/10.10.164.133\/prodcast\/","url":"http:\/\/10.10.164.133\/prodcast\/","name":"ProdCast - PayU Blog","isPartOf":{"@id":"https:\/\/payu.in\/blog\/#website"},"datePublished":"2026-06-01T06:00:51+00:00","dateModified":"2026-06-01T07:58:22+00:00","author":{"@id":"https:\/\/payu.in\/blog\/#\/schema\/person\/53f4d6cd68d042768a86e784c4c59294"},"breadcrumb":{"@id":"http:\/\/10.10.164.133\/prodcast\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["http:\/\/10.10.164.133\/prodcast\/"]}]},{"@type":"BreadcrumbList","@id":"http:\/\/10.10.164.133\/prodcast\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/payu.in\/blog\/"},{"@type":"ListItem","position":2,"name":"Engineering Blogs","item":"http:\/\/10.10.164.133\/category\/engineering-blogs\/"},{"@type":"ListItem","position":3,"name":"ProdCast"}]},{"@type":"WebSite","@id":"https:\/\/payu.in\/blog\/#website","url":"https:\/\/payu.in\/blog\/","name":"PayU Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/payu.in\/blog\/?s={search_term_string}"},"query-input":"required name=search_term_string"}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/payu.in\/blog\/#\/schema\/person\/53f4d6cd68d042768a86e784c4c59294","name":"Dev Pratap Singh","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/payu.in\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/a8dea061f69a548552b66d2ebddf2605?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/a8dea061f69a548552b66d2ebddf2605?s=96&d=mm&r=g","caption":"Dev Pratap Singh"},"url":"https:\/\/payu.in\/blog\/author\/dev-singh\/"}]}},"_links":{"self":[{"href":"https:\/\/payu.in\/blog\/wp-json\/wp\/v2\/posts\/15473"}],"collection":[{"href":"https:\/\/payu.in\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/payu.in\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/payu.in\/blog\/wp-json\/wp\/v2\/users\/94"}],"replies":[{"embeddable":true,"href":"https:\/\/payu.in\/blog\/wp-json\/wp\/v2\/comments?post=15473"}],"version-history":[{"count":10,"href":"https:\/\/payu.in\/blog\/wp-json\/wp\/v2\/posts\/15473\/revisions"}],"predecessor-version":[{"id":15561,"href":"https:\/\/payu.in\/blog\/wp-json\/wp\/v2\/posts\/15473\/revisions\/15561"}],"wp:attachment":[{"href":"https:\/\/payu.in\/blog\/wp-json\/wp\/v2\/media?parent=15473"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/payu.in\/blog\/wp-json\/wp\/v2\/categories?post=15473"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/payu.in\/blog\/wp-json\/wp\/v2\/tags?post=15473"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}