EndpointVault

EndpointVault: encrypted capture + endpoint reliability stats for critical API calls in Flutter. Never lose unique user data, see failing endpoints fast, replay/verify after fixes.

Comment

About the Project

Inspiration

I’m a Flutter developer working on apps that must function offline, collect important user data, and later synchronize it with a backend.
In one real project, users spend 10–20 minutes walking through a building, talking to people, and filling in structured information. Losing that data is not acceptable.

At the same time, the backend is developed by another team. Like many modern teams, they move fast and sometimes vibecode — shipping features quickly without full test coverage or deep consideration of edge cases.

The result is familiar to many mobile developers:

  • the app works correctly,
  • the network is flaky or the backend returns 500,
  • the user finishes their work,
  • and the data can be lost or stuck.

Of course, we can add server-side logs and monitoring.
We can see that errors happened.

But logs don’t recover lost data.

When a critical request fails — a payment, a form, a document upload — the user’s work may already be gone.
And building a full recovery and observability infrastructure is complex and expensive for many teams.

I needed a way to:

  • never lose critical data, even when requests fail,
  • understand which endpoints break and how often, and
  • solve issues before users complain.

That need became EndpointVault.

What I Learned

While building EndpointVault, I learned that the first visible bug is rarely the only problem.

Once I started collecting failed requests and aggregating statistics per endpoint, new issues emerged:

  • one specific endpoint was refreshing auth tokens 10× more often than others,
  • unnecessary retries were hidden behind “successful” user flows,
  • backend inefficiencies became visible only when seen as patterns, not logs.

I also learned that:

  • observability for business-critical requests is very different from generic logging,
  • mobile apps need failure-aware architecture, not just retries,
  • and early signals allow teams to fix problems before users even notice.

Most importantly:
seeing errors is not enough — you must be able to recover the data.

How I Built It

EndpointVault consists of two main parts.

1. Flutter Client (Dio-level interception)

  • Implemented as a Dio interceptor in Flutter
  • Developers explicitly mark requests as critical
  • On failure (5xx, timeouts, network errors):
    • request metadata is captured,
    • sensitive fields are redacted,
    • payloads can be encrypted,
    • and the event is queued and sent reliably

This works even when the app operates offline and synchronizes later.

Instead of losing the payload, the data is preserved safely.

2. Serverpod Backend

  • Built with Serverpod (open source)
  • Can run on Serverpod Cloud or self-hosted on AWS
  • Responsibilities:
    • store failed request events,
    • aggregate endpoint-level statistics,
    • provide a simple dashboard,
    • trigger alerts (email / Slack / webhooks),
    • support verification or resend after backend fixes

Serverpod was a natural fit because it provides a clean, structured backend architecture while remaining transparent and easy to deploy.

What Makes EndpointVault Different

EndpointVault is not just another logging tool.

Traditional logging tells you something failed.
EndpointVault lets you:

  • preserve the failed data
  • recover or resend it later
  • see reliability statistics per endpoint
  • get alerts early
  • and start with almost zero setup

Teams don’t need to build complex infrastructure.
They simply register, get an API key, and start sending events.

Challenges Faced

Designing for Trust

This project deals with potentially sensitive data. A major challenge was designing the system so that:

  • data minimization is the default,
  • encryption is supported,
  • and teams keep control over what is stored and for how long.

Replay Is Not Always Simple

Not all requests can be replayed from a server:

  • some require short-lived user tokens,
  • some must be re-sent from the device.

This led to a dual recovery model:

  • server-side verification when possible,
  • device-side resend when required.

Keeping It Simple

Many observability tools require heavy backend setup and configuration.
A key challenge was making EndpointVault simple enough that small teams can adopt it in minutes, not days.

Why It Matters

Errors will always happen — even in well-tested systems.

EndpointVault helps teams:

  • see which endpoints fail and how often,
  • preserve valuable user data when failures occur,
  • recover data instead of losing it,
  • discover backend issues before users report them, and
  • ship faster without fear of silent data loss.

What started as a solution for one project turned into something that can help any team building real-world mobile apps, whether they vibecode or not.

Commercial Direction

EndpointVault is designed as a commercial B2B service, not just a hackathon prototype.

I have already prepared a public landing page
👉 https://endpoint.yahhi.me/

and documentation for integrating the Flutter package into real projects.

The intended flow is simple:

  • teams register,
  • create a project,
  • receive API keys,
  • and start sending critical failure events to EndpointVault.

No heavy backend setup required.

At the moment, EndpointVault is used in my own projects and by my first client.
In parallel, I’m preparing onboarding, infrastructure, and documentation so other teams can adopt it as a paid service.

The goal is to provide a ready-to-use solution for endpoint reliability, data preservation, and early incident detection, without forcing teams to build their own complex recovery systems.

Built With

Share this project:

Updates