<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Api on Cesar Gimenes</title><link>https://crg.eti.br/tags/api/</link><description>Recent content in Api on Cesar Gimenes</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>crg@crg.eti.br (Cesar Gimenes)</managingEditor><webMaster>crg@crg.eti.br (Cesar Gimenes)</webMaster><lastBuildDate>Sat, 19 Sep 2026 15:27:44 -0300</lastBuildDate><atom:link href="https://crg.eti.br/tags/api/index.xml" rel="self" type="application/rss+xml"/><item><title>Why Your API Needs a Tracking ID</title><link>https://crg.eti.br/pub/tracking_id/</link><pubDate>Sat, 19 Sep 2026 15:27:44 -0300</pubDate><author>crg@crg.eti.br (Cesar Gimenes)</author><guid>https://crg.eti.br/pub/tracking_id/</guid><description>&lt;p>This isn&amp;rsquo;t the TraceID (or trace_id) used in distributed tracing. The TraceID identifies a trace and is propagated between services; it can even arrive at your API from the client. And tracing works with queues too, as the &lt;a href="https://opentelemetry.io/docs/specs/semconv/messaging/messaging-spans/">OpenTelemetry messaging conventions&lt;/a> show.&lt;/p>
&lt;p>But if your API is asynchronous, processing events through queues, you need an operation tracking ID to correlate events that belong to the same job, even when they span different traces. Under this contract, instead of being generated at the API entry point, the tracking ID must be generated and sent by the client, following whatever ID generation rules you define. The client needs to save this ID before the first request and reuse it when retrying the same operation.&lt;/p></description></item></channel></rss>