{"id":103422,"date":"2026-03-11T14:00:11","date_gmt":"2026-03-11T08:30:11","guid":{"rendered":"https:\/\/www.guvi.in\/blog\/?p=103422"},"modified":"2026-03-20T04:09:44","modified_gmt":"2026-03-19T22:39:44","slug":"how-to-write-a-change-log","status":"publish","type":"post","link":"https:\/\/www.guvi.in\/blog\/how-to-write-a-change-log\/","title":{"rendered":"How to Write a Change Log: Structure, Examples, Tools, and Best Practices for Software Releases"},"content":{"rendered":"\n<p>Software products are updated regularly with new features, bug fixes, performance improvements, and security updates. As teams release new versions, developers and users need a clear way to see what has changed. Without proper documentation, it becomes difficult to track updates across versions, especially when many people contribute to the project.<\/p>\n\n\n\n<p>A change log solves this problem by maintaining a chronological record of updates made to a software project. It documents new features, modifications, bug fixes, and other important changes associated with each version. This record helps development teams maintain transparency, simplifies troubleshooting, and allows users to quickly understand how a product has evolved over time.<\/p>\n\n\n\n<p>Read this blog to learn what a change log is, why teams maintain it, how it is structured, and the best ways to document software updates.<\/p>\n\n\n\n<p><strong>Quick Answer: <\/strong>A change log records software updates across versions, including new features, bug fixes, improvements, and security patches. It organizes updates by release to help teams track changes, improve debugging, maintain transparency, and communicate product updates clearly to developers and users.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>What Is a Change Log?<\/strong><\/h2>\n\n\n\n<p>A change log is a documented record of modifications made to a software project across different versions. It provides a chronological summary of updates such as newly introduced features, improvements to existing functionality, resolved defects, and security patches. Each release typically includes a structured entry that lists the changes associated with that version.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>How to Write a Change Log: Core Principles<\/strong><\/h2>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>1. Document Changes at the Release Level<\/strong><\/h3>\n\n\n\n<p>Change logs should summarize updates introduced in a specific software release, not individual commits. Commit histories often contain detailed technical changes that are difficult for broader teams to interpret.<\/p>\n\n\n\n<p>Instead, group relevant updates under a version identifier and present them as release summaries. This approach provides a clear view of how the system changed between versions.<\/p>\n\n\n\n<p><strong>Example<\/strong><\/p>\n\n\n\n<p><strong>Version:<\/strong> 3.1.0<br><strong>Release Date:<\/strong> April 2026<\/p>\n\n\n\n<p><strong>Added<\/strong><\/p>\n\n\n\n<ul>\n<li>Batch shipment processing <a href=\"https:\/\/www.guvi.in\/blog\/api-response-structure-best-practices\/\" target=\"_blank\" rel=\"noreferrer noopener\">API<\/a><\/li>\n<\/ul>\n\n\n\n<p><strong>Changed<\/strong><\/p>\n\n\n\n<ul>\n<li>Optimized database indexing for route planning queries<\/li>\n<\/ul>\n\n\n\n<p><strong>Fixed<\/strong><\/p>\n\n\n\n<ul>\n<li>Corrected fleet tracking synchronization issue<\/li>\n<\/ul>\n\n\n\n<p>Release summaries help readers understand system updates without reviewing hundreds of commits.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>2. Use Consistent Categories for Updates<\/strong><\/h3>\n\n\n\n<p>Consistency improves readability across long release histories. Development teams should organize updates under predefined categories.<\/p>\n\n\n\n<p><strong>Common categories<\/strong><\/p>\n\n\n\n<ul>\n<li><strong>Added<\/strong>: New features or capabilities<\/li>\n\n\n\n<li><strong>Changed<\/strong>: Modifications to existing functionality<\/li>\n\n\n\n<li><strong>Deprecated<\/strong>: Features planned for removal<\/li>\n\n\n\n<li><strong>Removed<\/strong>: Features that are no longer supported<\/li>\n\n\n\n<li><strong>Fixed<\/strong>: Bug fixes and defect corrections<\/li>\n\n\n\n<li><strong>Security<\/strong>: Vulnerability fixes and security improvements<\/li>\n<\/ul>\n\n\n\n<p>A consistent structure allows readers to scan updates quickly and compare changes across versions. Many projects follow the Keep a Changelog format because it provides a widely accepted structure for release documentation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>3. Write Clear and Specific Descriptions<\/strong><\/h3>\n\n\n\n<p>Each change log entry should describe updates with precision. Readers should understand what changed and how it affects the system.<\/p>\n\n\n\n<p><strong>Weak description<\/strong><\/p>\n\n\n\n<ul>\n<li>Improved performance<\/li>\n<\/ul>\n\n\n\n<p><strong>Clear description<\/strong><\/p>\n\n\n\n<ul>\n<li>Reduced API response latency by optimizing query caching in the route planning service<\/li>\n<\/ul>\n\n\n\n<p>Specific descriptions help engineers analyze system behavior across releases and support debugging when performance or stability issues occur.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>4. Maintain Structured Versioning<\/strong><\/h3>\n\n\n\n<p>Version identifiers help readers understand the scale of a release. Many software projects follow semantic <a href=\"https:\/\/www.guvi.in\/hub\/git-guide\/introduction-to-git\/\" target=\"_blank\" rel=\"noreferrer noopener\">versioning<\/a>, which uses the format:<\/p>\n\n\n\n<p>MAJOR.MINOR.PATCH<\/p>\n\n\n\n<p><strong>Example<\/strong><\/p>\n\n\n\n<p>2.5.1<\/p>\n\n\n\n<p>Version meanings:<\/p>\n\n\n\n<ul>\n<li><strong>Major<\/strong>: Architectural changes or breaking updates<\/li>\n\n\n\n<li><strong>Minor<\/strong>: New features that remain backward compatible<\/li>\n\n\n\n<li><strong>Patch<\/strong>: Small fixes such as bug corrections<\/li>\n<\/ul>\n\n\n\n<p>Structured versioning allows readers to evaluate the impact of a release before reviewing detailed updates.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>5. Record Deprecations Before Removal<\/strong><\/h3>\n\n\n\n<p>Removing functionality without prior notice can disrupt integrations and development workflows. Change logs should record deprecation notices before removing features.<\/p>\n\n\n\n<p>Deprecation entries inform developers that a feature will be removed in a future release. This provides time to migrate to alternative implementations.<\/p>\n\n\n\n<p><strong>Example<\/strong><\/p>\n\n\n\n<p><strong>Deprecated<\/strong><\/p>\n\n\n\n<ul>\n<li>Legacy shipment status API scheduled for removal in version 4.0<\/li>\n<\/ul>\n\n\n\n<p>This approach maintains backward compatibility and reduces disruption across dependent systems.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>6. Keep Entries Concise but Informative<\/strong><\/h3>\n\n\n\n<p>Change log entries should communicate updates clearly without unnecessary detail. The focus should be on the impact of the change, not the entire development process.<\/p>\n\n\n\n<p><strong>Example<\/strong><\/p>\n\n\n\n<ul>\n<li>Added delivery route clustering algorithm for high density urban zones<\/li>\n<\/ul>\n\n\n\n<p>This description communicates the system update clearly while avoiding excessive implementation detail.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>7. Update the Change Log During Development<\/strong><\/h3>\n\n\n\n<p>Maintaining change logs only during release preparation often results in missing updates. A more reliable approach is to update the document continuously during development.<\/p>\n\n\n\n<p>Teams typically update the change log when:<\/p>\n\n\n\n<ul>\n<li>Pull requests are merged<\/li>\n\n\n\n<li>New features are completed<\/li>\n\n\n\n<li>Bugs are fixed<\/li>\n\n\n\n<li>Security patches are implemented<\/li>\n<\/ul>\n\n\n\n<p>Continuous documentation improves accuracy and prevents gaps in release history.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>8. Separate Change Logs from Release Notes<\/strong><\/h3>\n\n\n\n<p>Although related, change logs and release notes serve different purposes.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td><strong>Change Log<\/strong><\/td><td><strong>Release Notes<\/strong><\/td><\/tr><tr><td>Technical summary of updates<\/td><td>User focused explanation of product updates<\/td><\/tr><tr><td>Written for developers and stakeholders<\/td><td>Written for end users<\/td><\/tr><tr><td>Organized by update categories<\/td><td>Organized by product improvements<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Development teams often maintain both. The change log documents technical modifications, while release notes explain product updates in simpler language.<\/p>\n\n\n\n<p><em>Want to go beyond software release basics like writing changelogs and build real AI systems used in production? Master machine learning fundamentals, model development, deployment, and real-world AI workflows with HCL GUVI\u2019s <\/em><a href=\"https:\/\/www.guvi.in\/mlp\/artificial-intelligence-and-machine-learning\/?utm_source=blog&amp;utm_medium=hyperlink&amp;utm_campaign=how-to-write-a-changelog-structure-examples-tools-and-best-practices-for-software-releases\" target=\"_blank\" rel=\"noreferrer noopener\"><strong><em>Artificial Intelligence &amp; Machine Learning Course<\/em><\/strong><\/a><em>.<\/em><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Changelog Examples &amp; Samples<\/strong><\/h2>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Example 1: Standard Software Release Changelog<\/strong><\/h3>\n\n\n\n<p><strong>Version:<\/strong> 2.3.0<br><strong>Release Date:<\/strong> March 2026<\/p>\n\n\n\n<p><strong>Added<\/strong><\/p>\n\n\n\n<ul>\n<li>Route clustering module for multi-stop delivery planning<\/li>\n\n\n\n<li>Export option for shipment performance reports<\/li>\n<\/ul>\n\n\n\n<p><strong>Changed<\/strong><\/p>\n\n\n\n<ul>\n<li>Improved database indexing for fleet tracking queries<\/li>\n\n\n\n<li>Updated user dashboard layout for faster navigation<\/li>\n<\/ul>\n\n\n\n<p><strong>Fixed<\/strong><\/p>\n\n\n\n<ul>\n<li>Resolved GPS coordinate mismatch during driver tracking<\/li>\n\n\n\n<li>Corrected calculation error in fuel usage analytics<\/li>\n<\/ul>\n\n\n\n<p><strong>Security<\/strong><\/p>\n\n\n\n<ul>\n<li>Updated OAuth authentication library to address token validation vulnerability<\/li>\n<\/ul>\n\n\n\n<p>This format provides a clear summary of system updates while separating different types of changes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Example 2: API Platform Changelog<\/strong><\/h3>\n\n\n\n<p><strong>Version:<\/strong> 1.8.2<br><strong>Release Date:<\/strong> February 2026<\/p>\n\n\n\n<p><strong>Added<\/strong><\/p>\n\n\n\n<ul>\n<li>New endpoint \/routes\/optimize for batch route optimization<\/li>\n\n\n\n<li>Webhook support for delivery status notifications<\/li>\n<\/ul>\n\n\n\n<p><strong>Changed<\/strong><\/p>\n\n\n\n<ul>\n<li>Increased API rate limit for authenticated enterprise accounts<\/li>\n\n\n\n<li>Improved response compression for location tracking endpoints<\/li>\n<\/ul>\n\n\n\n<p><strong>Fixed<\/strong><\/p>\n\n\n\n<ul>\n<li>Corrected pagination issue in shipment history endpoint<\/li>\n\n\n\n<li>Resolved timeout error for large routing requests<\/li>\n<\/ul>\n\n\n\n<p><strong>Deprecated<\/strong><\/p>\n\n\n\n<ul>\n<li>Legacy endpoint \/routes\/basic scheduled for removal in version 2.0<\/li>\n<\/ul>\n\n\n\n<p>API changelogs often highlight endpoint updates, performance improvements, and deprecations.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Example 3: Open Source Project Changelog<\/strong><\/h3>\n\n\n\n<p><strong>Version:<\/strong> 4.1.0<br><strong>Release Date:<\/strong> January 2026<\/p>\n\n\n\n<p><strong>Added<\/strong><\/p>\n\n\n\n<ul>\n<li>Plugin architecture for extending analytics modules<\/li>\n\n\n\n<li>Command line interface for batch data processing<\/li>\n<\/ul>\n\n\n\n<p><strong>Changed<\/strong><\/p>\n\n\n\n<ul>\n<li>Refactored caching layer to improve memory usage<\/li>\n\n\n\n<li>Updated logging framework for structured log output<\/li>\n<\/ul>\n\n\n\n<p><strong>Fixed<\/strong><\/p>\n\n\n\n<ul>\n<li>Resolved memory leak in asynchronous processing module<\/li>\n\n\n\n<li>Corrected configuration parsing issue in YAML loader<\/li>\n<\/ul>\n\n\n\n<p>Open source projects maintain detailed changelogs to help contributors and users track project evolution.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Example 4: Mobile Application Changelog<\/strong><\/h3>\n\n\n\n<p><strong>Version:<\/strong> 5.2.1<br><strong>Release Date:<\/strong> March 2026<\/p>\n\n\n\n<p><strong>Added<\/strong><\/p>\n\n\n\n<ul>\n<li>Dark mode support for user interface<\/li>\n\n\n\n<li>Real-time delivery notifications<\/li>\n<\/ul>\n\n\n\n<p><strong>Changed<\/strong><\/p>\n\n\n\n<ul>\n<li>Improved loading speed for order tracking screen<\/li>\n\n\n\n<li>Updated navigation layout for easier access to delivery history<\/li>\n<\/ul>\n\n\n\n<p><strong>Fixed<\/strong><\/p>\n\n\n\n<ul>\n<li>Resolved login session expiration issue<\/li>\n\n\n\n<li>Corrected location pin placement on delivery map<\/li>\n<\/ul>\n\n\n\n<p>Mobile application changelogs often focus on user interface updates, performance improvements, and bug fixes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Example 5: Enterprise SaaS Platform Changelog<\/strong><\/h3>\n\n\n\n<p><strong>Version:<\/strong> 7.4.0<br><strong>Release Date:<\/strong> April 2026<\/p>\n\n\n\n<p><strong>Added<\/strong><\/p>\n\n\n\n<ul>\n<li>Multi warehouse inventory synchronization<\/li>\n\n\n\n<li>Advanced analytics dashboard for logistics performance<\/li>\n<\/ul>\n\n\n\n<p><strong>Changed<\/strong><\/p>\n\n\n\n<ul>\n<li>Optimized query processing for large shipment datasets<\/li>\n\n\n\n<li>Updated access control rules for administrative users<\/li>\n<\/ul>\n\n\n\n<p><strong>Fixed<\/strong><\/p>\n\n\n\n<ul>\n<li>Resolved delayed status updates in shipment tracking service<\/li>\n\n\n\n<li>Corrected invoice generation error for bulk orders<\/li>\n<\/ul>\n\n\n\n<p><strong>Security<\/strong><\/p>\n\n\n\n<ul>\n<li>Strengthened encryption standards for stored customer data<\/li>\n<\/ul>\n\n\n\n<p>Enterprise software changelogs often document system capabilities, operational improvements, and security updates.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Top Benefits of Maintaining a Change Log<\/strong><\/h2>\n\n\n\n<ul>\n<li><strong>Improves Release Transparency: <\/strong>A change log provides a clear record of updates introduced in each release. Developers, product teams, and users can quickly understand what has changed without reviewing commit histories.<\/li>\n\n\n\n<li><strong>Supports Faster <\/strong><a href=\"https:\/\/www.guvi.in\/blog\/debugging-in-software-development\/\" target=\"_blank\" rel=\"noreferrer noopener\"><strong>Debugging<\/strong><\/a><strong>: <\/strong>When issues appear in production, engineers can review recent change log entries to identify updates that may have affected system behavior. This helps narrow down potential causes during troubleshooting.<\/li>\n\n\n\n<li><strong>Improves Communication with Users: <\/strong>Users often review change logs to understand how a product has improved or which issues have been resolved. Clear documentation increases transparency and helps users decide when to update.<\/li>\n\n\n\n<li><strong>Supports Compliance and Audit Requirements: <\/strong>Organizations in regulated industries must maintain records of system modifications. Change logs provide traceable documentation of updates across software releases.<\/li>\n\n\n\n<li><strong>Simplifies Release Management: <\/strong>During deployment cycles, change logs help teams track what updates are included in each release. This improves coordination across development, testing, and operations workflows.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Top Five Tools for Managing Change Logs<\/strong><\/h2>\n\n\n\n<ol>\n<li><strong>Git-Based Change Log Generators: <\/strong>Tools that analyze Git commit history and pull requests to automatically generate change log entries. They extract structured updates from commit messages and group them by release version. This approach reduces manual documentation effort while maintaining alignment with the repository history.<\/li>\n\n\n\n<li><strong>Release Automation Platforms: <\/strong>Release management tools integrate with <a href=\"https:\/\/www.guvi.in\/blog\/understanding-ci-cd\/\" target=\"_blank\" rel=\"noreferrer noopener\">CI\/CD pipelines<\/a> and generate change logs during deployment workflows. They compile merged pull requests, tag releases, and produce structured release documentation that reflects the exact changes introduced in each deployment.<\/li>\n\n\n\n<li><strong>Repository Hosting Platforms: <\/strong>Platforms that host source code repositories often include built in release documentation features. Teams can create version tags, publish release summaries, and attach change logs directly to repository releases, providing a central reference for development updates.<\/li>\n\n\n\n<li><strong>Documentation Management Systems: <\/strong>Technical documentation platforms allow teams to maintain structured change logs alongside product documentation. This approach keeps release history accessible to both engineers and product stakeholders.<\/li>\n\n\n\n<li><strong>Continuous Integration Pipeline Integrations: <\/strong>CI systems can collect committed metadata and release artifacts during build pipelines. These systems help development teams maintain accurate change logs that reflect verified builds and production releases.<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Best Practices for Maintaining Change Logs<\/strong><\/h2>\n\n\n\n<ul>\n<li><strong>Follow a Consistent Structure: <\/strong>Organize entries using defined categories such as Added, Changed, Fixed, Deprecated, and Security. Consistent formatting improves readability and makes release histories easier to analyze.<\/li>\n\n\n\n<li><strong>Document Changes at the Release Level: <\/strong>Summarize updates introduced in each software version rather than listing individual commits. This provides a clear overview of system changes across releases.<\/li>\n\n\n\n<li><strong>Write Precise and Technical Descriptions: <\/strong>Each entry should explain the actual system update rather than using vague phrases such as improvements or updates. Clear descriptions support debugging and system analysis.<\/li>\n\n\n\n<li><strong>Maintain Versioning Discipline: <\/strong>Use structured version identifiers such as semantic versioning. Version numbering helps readers interpret the scale and impact of each release.<\/li>\n\n\n\n<li><strong>Record Deprecation Notices Early: <\/strong>Document deprecated features before removing them from the system. This gives developers time to migrate integrations or update dependent systems.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Conclusion<\/strong>&nbsp;<\/h2>\n\n\n\n<p>In modern <a href=\"https:\/\/www.guvi.in\/blog\/what-is-software-development\/\" target=\"_blank\" rel=\"noreferrer noopener\">software development<\/a>, where products evolve through frequent releases and collaborative contributions, maintaining clear documentation of system updates is essential. A well-structured change log provides this clarity by recording feature additions, system modifications, bug fixes, and security updates across versions in a consistent and accessible format.&nbsp;<\/p>\n\n\n\n<p>Beyond documentation, change logs support debugging, improve release transparency, assist compliance efforts, and help users understand how a product progresses over time. When maintained consistently, a change log becomes an important operational reference that strengthens communication across engineering teams, stakeholders, and users.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>FAQs<\/strong><\/h2>\n\n\n<div id=\"rank-math-faq\" class=\"rank-math-block\">\n<div class=\"rank-math-list \">\n<div id=\"faq-question-1773183347386\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>1. How often should a change log be updated?<\/strong><\/h3>\n<div class=\"rank-math-answer \">\n\n<p>A change log should be updated whenever meaningful changes occur during development. Many teams update it when pull requests are merged, bugs are resolved, or features are completed so that release documentation remains accurate.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1773183359383\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>2. Who is responsible for maintaining a change log?<\/strong><\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Responsibility usually falls on the development team, but many organizations assign ownership to release managers or technical writers who compile updates from engineering commits and deployment notes.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1773183376400\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>3. Where should a change log be published?<\/strong><\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Change logs are commonly published in project repositories, documentation portals, or product release pages. Hosting them in a central location helps developers, stakeholders, and users easily access the release history.<\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Software products are updated regularly with new features, bug fixes, performance improvements, and security updates. As teams release new versions, developers and users need a clear way to see what has changed. Without proper documentation, it becomes difficult to track updates across versions, especially when many people contribute to the project. A change log solves [&hellip;]<\/p>\n","protected":false},"author":60,"featured_media":103568,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[933],"tags":[],"views":"582","authorinfo":{"name":"Vaishali","url":"https:\/\/www.guvi.in\/blog\/author\/vaishali\/"},"thumbnailURL":"https:\/\/www.guvi.in\/blog\/wp-content\/uploads\/2026\/03\/Change-Log-300x112.webp","jetpack_featured_media_url":"https:\/\/www.guvi.in\/blog\/wp-content\/uploads\/2026\/03\/Change-Log.webp","_links":{"self":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/103422"}],"collection":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/users\/60"}],"replies":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/comments?post=103422"}],"version-history":[{"count":8,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/103422\/revisions"}],"predecessor-version":[{"id":104282,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/103422\/revisions\/104282"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/media\/103568"}],"wp:attachment":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/media?parent=103422"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/categories?post=103422"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/tags?post=103422"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}