From API Logs to Business Insights: My APIConf 2025 Talk

Last month, I had the privilege of speaking at APIConf 2025, hosted by APIDays. The conference theme revolved around APIs, a topic that, at first glance, feels deeply rooted in software engineering. As a data analyst, I saw an opportunity to approach it differently: to show how API data, when enriched and visualized, can speak volumes not just to developers, but also to business leaders, product managers, and operations teams.

Why APIs Matter Beyond the Code

APIs may be technical in nature, but the logs they generate are much more than error codes and timestamps. Every log is a story: a customer trying to check out, a payment processing attempt, a product search, a login request. Hidden in those logs are indicators of customer behavior, operational bottlenecks, and revenue impact.

In my talk, "APIs Don’t Talk, But Dashboards Do", I demonstrated how enriched metrics can turn raw API logs into business intelligence.

Why Enrich API Logs?

Raw logs are noisy, technical, and difficult for non-engineers to interpret. By enriching logs with context like cart value, device type, region, or upstream service, we transform them into a shared language for technical and business teams. This enrichment allows dashboards to move beyond simple monitoring and into decision-making territory.

Below is a table showing some of the enriched fields I derived for this project, alongside how each was calculated (e.g., via DAX in Power BI or preprocessing in Python). This step was critical in bridging raw API logs with insights that both engineers and managers can act on:

The Dashboard Breakdown

KPI Cards:

• Revenue Lost: $464.85K – Derived from cart value tied to failed transactions, showing the direct financial cost of API failures.

• Transactions: 10,000 – Total API calls processed in the observed period.

• Errors: 4,985 – Nearly 50% of calls failed (status code 5xx), highlighting system instability.

• Average Response Time: 849.56ms – Above the <500ms industry benchmark, signaling degraded performance.

  
  

Latency Category:

• Fast (<400ms): 8%

• Moderate (400–900ms): 64%

• Slow (>900ms): 28%

• Most calls fall in the moderate range, but nearly 1 in 3 are slow – an experience risk for users.

  
  

Average Response Time by Day & Peak Hour:

• Peak-hour responses are consistently slower, especially on Days 1 and 7.

• The trendline shows worsening performance during high traffic.

  
  

Status Code by Endpoint & Method:

• /product and /cart are the most error-prone.

• POST requests fail more often than GET, indicating issues during data creation or updates.

  
  

Status Code by Upstream Service:

• Failures are spread across multiple services: Recommendation Engine (26%), Inventory Service (25%), User Auth (25%), Payment Gateway (24%).

Cart Value by Device Type:

• Tablets lead in cart value ($162.9K), followed by desktop and mobile – small user base, high purchase intent.

  
  

Cart Value by Region:

• US and Africa top the list, signaling potential focus areas for optimization.

  
  

Peak Hour Distribution:

• 87% of traffic is off-peak, which can guide capacity planning.

Insights and Recommendations

1. Revenue Lost equals $464.85K due to failed transactions

• Insight: Almost half of calls failed. The loss is concentrated around product and cart flows.

• Recommendation: Stabilise product and cart endpoints and POST requests first. Expect immediate revenue recovery.

  
  

2. Response Times average 849 ms with 28 percent slow calls

• Insight: Latency exceeds the 500 ms benchmark. Slow experiences drive abandonment.

• Recommendation: Add caching on product detail and cart, optimise database queries, and push static content to the edge.

  
  

3. Peak Hour Performance Degradation

• Insight: Days 1 and 7 show the sharpest slowdowns. Most traffic is outside the current peak definition.

• Recommendation: Redefine peak windows from real data and update autoscaling rules to match observed demand.

  
  

4. Endpoint and Method Failures

• Insight: POST operations fail more than GET. Write paths are fragile.

• Recommendation: Add idempotency keys, improve retry logic with backoff, and expand test coverage for create or update flows.

  
  

5. Upstream Service Distribution

• Insight: Failures span recommendation, inventory, auth, and payments. No single point of failure.

• Recommendation: Run joint reliability reviews and set shared service level objectives across teams.

  
  

6. Cart Value by Device and Region

• Insight: Tablet users are high value. US and Africa drive significant value.

• Recommendation: Improve tablet checkout UX and prioritise infra reliability in those regions. Tailor promos and payment options to local preferences.

  
  

7. Off Peak Traffic Dominance at 87 percent

• Insight: Actual user behaviour does not match assumed peak windows.

• Recommendation: Shift maintenance windows and scheduled jobs away from off peak to true low demand hours.

Why This Matters and To Whom

• Business Leaders: See the dollar impact of technical issues.

• Product Managers: Identify which customer journeys are breaking most.

• Engineering Teams: Pinpoint which services or endpoints to stabilize.

• Operations Teams: Optimize infrastructure based on demand patterns.

Limitations and Assumptions

• Dataset is a representative sample for demonstration.

• Region granularity is at country or region, not city.

• Peak hour definition is configurable and may differ across geographies.

  
  

Closing Thoughts

This project reinforced my belief that data analysts can play a role in deeply technical topics. By enriching and contextualising API logs, we bridge the gap between code and commerce and ensure that what happens in the backend informs better business decisions.

APPENDIX

How To Read These Dashboards

1. Start at the KPI cards to anchor on scale and urgency such as revenue risk and error volume.

2. Scan latency distribution to understand experience risk at a glance.

3. Check peak versus off peak to see when users feel the pain most.

4. Use endpoint by method and upstream service charts to locate root causes.

5. Move to the business lens to see who is affected by device and region and where to act first.

   
   

Power BI Build Notes

• Data ingestion: Power Query connects to log export files or a streaming endpoint. Normalise fields such as timestamp, status code, route, method, user agent, IP, and content length.

  
  

• Key DAX measures and columns:

  • Average Response Time ms: AVERAGE('Logs'[Response Time ms])

  • Errors: COUNTROWS(FILTER('Logs', 'Logs'[Is Error] = TRUE))

  • Error Rate percent: DIVIDE([Errors], [Transactions])

  • Revenue Lost: SUMX(FILTER('Logs', 'Logs'[Is Error] = TRUE), 'Logs'[Cart Value USD])

  • Latency Category: IF('Logs'[Response Time ms] < 400, "Fast", IF('Logs'[Response Time ms] <= 900, "Moderate", "Slow"))

  • Is Peak Hour: VAR h = HOUR('Logs'[Timestamp]) RETURN IF(h IN {6,7,8,9,10,17,18,19,20,21}, TRUE, FALSE)

  • Trend 7d ms: CALCULATE([Average Response Time ms], DATESINPERIOD('Date'[Date], MAX('Date'[Date]), -7, DAY))

Note: adjust DAX to your table names. Use a separate Date table with a one to many relationship to Logs for rolling windows.

Pipeline and Governance

• Source: API gateway or load balancer exports and application logs.

• Transform: Power Query for parsing and enrichment. Optional Python for heavy parsing.

• Model: Star schema with a fact table Logs and dimensions for Endpoint, Service, Device, Region, and Time.

• Refresh: Incremental refresh with partitioning by date.

• Privacy and ethics: Remove PII, hash user identifiers, and define a retention policy.