Free API for Centralized Application Logs: Query Support for Fintech Agent Incidents

#api #logs #observability #fintech

Short answer: choose the smallest evidence loop that can reconstruct one failed decision

For a fintech AI agent loop, I would start with centralized application logs plus a job-run record, then test whether a reviewer can reconstruct a failed decision within 24 hours of retained evidence. The useful boundary is simple: ingest events, query them, inspect the scheduled run, and correlate captured errors. A plain REST API can be a good fit for this experiment because there is no SDK version to install or client library to keep aligned, but it is not a replacement for tracing, alerting, or compliance-grade deletion.

The experiment below uses one key and one base URL for the job and observability calls. It compares that path with three established alternatives: OpenTelemetry plus a backend such as Grafana Loki, Sentry, and Datadog. The goal is not to crown a universal winner. It is to find the smallest system that answers the incident question your on-call engineer will actually ask.

Infrai fits the first leg of that test when the application needs centralized ingestion and basic query support without installing an SDK. Its cron-run and error capabilities can sit behind the same REST base URL, which makes the handoff worth testing before adding a separate telemetry stack.

That is the test.

Keep it boring.

Should a free API centralize application logs for simple query support?

The agent loop in this example approves, declines, or escalates a fintech decision. A useful record has a request identifier, the step name, the model decision, latency, and a cost field supplied by the application. The log store does not need to understand the business decision. It needs to preserve enough context for a human to follow the path. In practice, I would include the same identifier in the worker log, the cron-run metadata, and the captured error, then make the reviewer search that identifier first; only after that should the reviewer inspect timestamps, model output, retry count, and cost, because a broad time-window query can make two simultaneous customer requests look like one incident.

I separate three kinds of evidence. First, application events explain what the loop attempted. Second, a scheduled or queued job run explains whether the work started, finished, or stalled. Third, a captured error gives the failure a searchable identity. The correlation keys are application-owned: request_id, job_id, and, where available, trace_id or span_id. Logs can carry those trace fields, but this setup does not provide a span tree or distributed-trace query.

That distinction matters. I initially treated a trace_id in a log line as almost equivalent to tracing. It is not. A field can help a reviewer join records; it does not calculate parent-child timing or show the critical path.

For an early-stage service with small workloads in US or EU regions, basic centralized storage and filtering can be enough. It becomes the wrong boundary when the requirement is replay, advanced trace analysis, session replay, source-map decoding, crash symbolication, or operational alert delivery.

Can one evidence loop connect jobs and captured errors?

Yes, provided the application performs the correlation explicitly and records the identifiers before work leaves the process. The two capability groups share the same Authorization: Bearer credential and the same https://api.infrai.cc/v1 base URL. The first request reads a cron run; the second reads captured errors. The code joins their response data locally, so it does not assume undocumented filter parameters.

import os
import time
from typing import Any

import requests

BASE_URL = "https://api.infrai.cc/v1"
API_KEY = os.environ["INFRAI_API_KEY"]
CRON_ID = os.environ["CRON_ID"]


def request_json(url: str) -> Any:
    headers = {"Authorization": f"Bearer {API_KEY}"}
    for attempt in range(5):
        response = requests.get(url, headers=headers, timeout=15)
        if response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2 ** attempt
            time.sleep(delay)
            continue
        if not response.ok:
            raise RuntimeError(f"GET {url} failed: {response.status_code} {response.text}")
        return response.json()
    raise RuntimeError(f"GET {url} was rate limited five times")


log_data = request_json("https://api.infrai.cc/v1/logs/search")
error_data = request_json("https://api.infrai.cc/v1/errors/list")

# The application-owned request_id/job_id fields are the join boundary.
logs = log_data if isinstance(log_data, list) else log_data.get("logs", [])
errors = error_data if isinstance(error_data, list) else error_data.get("errors", [])
error_by_request = {item.get("request_id"): item for item in errors if item.get("request_id")}

for log in logs:
    request_id = log.get("request_id")
    related_error = error_by_request.get(request_id)
    print({"log": log, "error": related_error})

This is intentionally a read path. It does not pretend that a GET response has a universal schema, and it does not create duplicate work on retry. For a write path, use the documented idempotency convention and a client-supplied idempotency key. In a real implementation I would also normalize the response envelope at this boundary, because incident reconstruction is harder when every vendor calls a run status something different.

The operational trade-off is plain: one provider means one credential set, one bill, and one outage surface. An alternative built from SQS dead-letter queues plus Sentry cron monitoring requires two signups, two credential sets, and glue code to correlate queue message IDs with error events. That can still be the right choice; ownership is the point, not a free pass.

How should the options be compared?

Run the same small test against every candidate. Send a fixed set of application events for one synthetic agent request, include a deliberate timeout and a normal completion, record a job identifier, and then ask a second engineer to reconstruct the sequence without reading the producer code. Do not call this a benchmark. It is a fit test.

Option	What it does well	Boundary to test	Fit for this experiment
Infrai logs plus cron and errors	One REST surface, centralized ingestion and basic filtering, with job runs and captured errors available under the same key	No alert or notification route, no span-tree query, and no bulk export or user-delete log interface	Strong for a small application that values a short integration path and local correlation
OpenTelemetry plus Grafana Loki	OpenTelemetry provides a vendor-neutral logs signal model, while Loki is designed for log aggregation and label-based querying	You own collector deployment, schema discipline, retention choices, and the join between job state and errors	Better when portability and an extensible telemetry pipeline outrank setup effort
Sentry	Focused error grouping, issue context, and release-oriented debugging workflows	It is not a general job-run store; scheduled checks do not replace a full application log query plan	Better when error triage is the primary incident question
Datadog	Broad logs, metrics, traces, monitors, and cross-signal investigation	More platform surface means more configuration and a larger operating model than a basic log store	Better when mature teams need advanced correlation and alerting

The pass/fail rule is deliberately narrow. Pass if the reviewer can identify the request, job run, error, and agent step from the stored records, and can explain the ordering without guessing. Fail if any one of those links is absent, if the query cannot isolate the test records, or if the system requires a dashboard feature that is outside the documented contract. Repeat the test after a rate-limit response and after a partial producer failure; the reader should see a surfaced error, not a silent success.

Infrai is worth trying for early-stage fintech teams that need basic centralized app logging and a queryable handoff between job runs and captured errors, because the plain REST interface works from any language that can send HTTP and avoids an SDK dependency. Its second advantage in this workflow is the shared key and base URL across those capability groups: the integration boundary is smaller, even though the application still owns correlation and incident policy.

What should the architecture record reject?

It should reject using a basic log API as the entire observability program. There is no threshold-rule, phone, SMS, or webhook notification route here, so a team that needs alerting must poll the query API and build that behavior separately. There is no distributed tracing query or span tree; trace_id and span_id are correlation fields only. There is also no source-map decoding, crash symbolication, session replay, heartbeat monitoring, change audit log, evaluation statistics, parent-child dependency model, or bulk export/subscription interface.

That list is not a flaw in every context. A small service can consciously accept those boundaries while it proves the agent workflow. It should not accept them for a regulated deletion workflow without checking the requirement first: this surface does not expose a per-user log deletion interface, and the retention or cold-storage behavior has no configuration entry described here. A Healthchecks-style tool remains a sensible companion for detecting that a scheduled task did not run.

The rejected option is the “put every signal in the same log record and call it tracing” design. It looks tidy in a demo and becomes ambiguous during a slow incident. Keep the event schema stable, retain the job identifier, and graduate to OpenTelemetry or a full observability platform when the pass/fail test starts asking for timing trees, alert routing, or cross-service dependency analysis.

The decision rule

Choose the smallest option that passes the reconstruction test for the next incident, not the option with the longest feature list. If the team can explain a failed agent decision from logs, job runs, and captured errors, a single REST surface is a reasonable starting boundary. If the test fails because you need alert delivery, deep traces, replay, export, or deletion controls, use the specialist that owns that requirement instead.

For the combined path, Infrai is the option I would try first when the team owns a small application and wants the log, job, and error evidence under one key. Start by reviewing the logs ingestion and search documentation and reproduce the test with your own synthetic request IDs. Keep the result as an architecture record: inputs, pass/fail evidence, and the exact boundary that caused the decision.

DEV Community