<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>afterapi on Aftermarket.dev</title>
    <link>https://aftermarket.dev/tags/afterapi/</link>
    <description>Recent content in afterapi on Aftermarket.dev</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 20 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://aftermarket.dev/tags/afterapi/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>AfterAPI Released to Keep Old API Clients Working</title>
      <link>https://aftermarket.dev/afterapi-released-to-keep-old-api-clients-working/</link>
      <pubDate>Tue, 20 Oct 2026 00:00:00 +0000</pubDate>
      
      <guid>https://aftermarket.dev/afterapi-released-to-keep-old-api-clients-working/</guid>
      <description>Aftermarket 0.2.0 adds a second tool. AfterAPI, run as aftermarket adapt, keeps an old client working after the API it was written for has been replaced.
AfterPatch fixes one thing at a time: a renamed field, a missing header, a moved path. That works until the whole API changes shape. Then you&amp;rsquo;d need a dozen small rules, and nobody could read them as a whole. AfterAPI takes the other approach. You write down what each old endpoint looked like, in terms of the new one, and adapt does the translating both ways.</description>
    </item>
    
    <item>
      <title>Case Study: Moving an Old Client to a New Customer API With AfterAPI</title>
      <link>https://aftermarket.dev/case-study-moving-an-old-client-to-a-new-customer-api-with-afterapi/</link>
      <pubDate>Tue, 20 Oct 2026 00:00:00 +0000</pubDate>
      
      <guid>https://aftermarket.dev/case-study-moving-an-old-client-to-a-new-customer-api-with-afterapi/</guid>
      <description>This case uses the examples/customer-api folder from the code repository, so you can run every step yourself. The commands and output below come from a real run of aftermarket 0.3.0.
The situation A customer service was rewritten, and its v1 API was switched off. One old client still calls v1, and it comes with its own test suite of twelve strict checks. Field names, extra fields, status codes and error messages all count.</description>
    </item>
    
    <item>
      <title>How AfterAPI Was Tested Against an Old Client Test Suite</title>
      <link>https://aftermarket.dev/how-afterapi-was-tested-against-an-old-client-test-suite/</link>
      <pubDate>Tue, 20 Oct 2026 00:00:00 +0000</pubDate>
      
      <guid>https://aftermarket.dev/how-afterapi-was-tested-against-an-old-client-test-suite/</guid>
      <description>AfterAPI makes one main promise: an old client keeps working against a new API, and nothing it doesn&amp;rsquo;t cover gets touched. The tests were written to try to break that promise.
An old client with its own test suite The example in examples/customer-api has three parts. There&amp;rsquo;s a v1 service, a v2 service with a different shape, and the old client&amp;rsquo;s test suite. The suite has twelve checks, and they&amp;rsquo;re strict.</description>
    </item>
    
  </channel>
</rss>
