API operations platform

Every request leaves a wake.

Flintwake sits at the edge of your API and keeps the whole record: who called, what they sent, how long it took, what broke and what it cost you. One console for traffic, keys, webhooks and the docs your consumers actually read.

Free for the first 2M requests a month. No card, no sales call.

Install the collector
# Put a collector in front of your API.
docker run -d --name flintwake \
  -e FLINTWAKE_API_KEY=$FLINTWAKE_API_KEY \
  -e FLINTWAKE_ORIGIN=https://api.internal.acme.dev \
  -p 8080:8080 flintwake/collector:4
First captured wake
POST/v2/payments/intents148ms201
x-flintwake-wake-id: wk_0c41f2a9
  • 48.2MRequests captured dailyAcross the demo account's three environments
  • 112msp95 at the edgeMeasured from first byte in to last byte out
  • 0.21%Error rateEvery failure attributed to an endpoint and a consumer
  • 34Connected destinationsAlerting, data warehouses, incident tooling

Trusted by the teams behind these fictional APIs

  • Northbank
  • Halyard
  • Cedarlift
  • Orrery
  • Pelham
  • Tessellate

The problem

Your API is a product. Most teams run it blind.

Gateway logs tell you a request happened. Application traces tell you what your own code did. Neither tells you which customer is about to churn because their integration has been getting 429s for a fortnight, or which endpoint quietly doubled its p99 after Tuesday's deploy.

  • 01

    The support ticket arrives before the alert

    A consumer emails a screenshot of a 500. Nobody can find the request. The thread runs for four days and ends in a guess.

  • 02

    Nobody owns the consumer's experience

    Your dashboards are per-service. Your customers experience per-integration. Those two views never meet, so regressions land on the people least able to fix them.

  • 03

    The docs drift from the API

    The reference says the field is optional. Production started rejecting it in March. The only people who know are the ones who stopped calling.

The console

Read the traffic, not the logs.

Switch environment, filter by status class and open any request. Everything below is the template's own interactive UI — no screenshots.

Open the full console
Request explorer
api.flintwake.com
  • Requests · 24h48.2M +6.4%
  • p95 latency112ms −9ms
  • Error rate0.21% −0.06pt
  • Active consumers1,284 +37
8 of 8 wakes
wk_0c41f2a9
201 148msiad1
content-type
application/json; charset=utf-8
x-flintwake-wake-id
wk_0c41f2a9
x-ratelimit-limit
6000
x-ratelimit-remaining
5842
x-ratelimit-reset
38
Response body
{
  "id": "pi_3QkL2xB",
  "object": "payment_intent",
  "amount": 24900,
  "status": "requires_capture",
  "created": 1789012458
}
Demonstration fixtures — no live traffic is captured by this template.

What it does

Four things, done properly.

Flintwake is not a dashboard bolted onto a log store. Each of these exists because an API team asked for it during an incident.

  • 01

    Capture every request as a wake

    See observability

    A wake is the full record of one call: request, response, timing breakdown, consumer, key, region and the downstream effects it triggered. Searchable for 30 days, replayable against any environment.

    • Structured capture at the edge, not in your app
    • Bodies redacted by rule before they leave your network
    • Replay a production failure against staging in one click
  • 02

    Read the API by consumer, not by service

    Open the console

    Every metric slices by the integration that produced it. You see which customer is hitting the timeout, which key is burning the quota and which SDK version is still sending the deprecated field.

    • Per-consumer latency, errors and quota
    • Deprecation tracking down to the SDK release
    • Quota warnings fired before the consumer notices
  • 03

    Ship keys, webhooks and limits without a ticket

    Explore the platform

    Scoped keys per environment, signed webhook delivery with automatic retry and replay, and rate limits you can change per consumer — all from the same console, all audited.

    • Scoped keys with one-click rotation and grace windows
    • Signed deliveries, exponential retry, manual replay
    • Per-consumer limit overrides with an audit trail
  • 04

    Docs that are generated from the same source

    Browse the reference

    The reference, the SDK snippets and the playground all read one schema. When an endpoint changes, the docs change with it and the changelog entry writes itself.

    • Reference generated from the live schema
    • Seven SDKs with matching examples
    • Playground calls the same fixtures your consumers test against

Observability

Latency and errors, attributable to a cause.

Change the range and the charts redraw. In the real product the same views annotate deploys and let you jump straight into the requests behind a spike.

Latency quantiles
p5042msp95112msp99236ms
011723435146800:0006:0012:0018:0024:00
p50 medianp95p99 tail
Errors by type
429Rate limit exceeded42,180
404Resource missing14,620
402Payment required4,880
500Internal error1,104
504Upstream timeout402
See endpoint and consumer analytics

Capabilities

Thirty things your API team stops building.

Every group below maps to a surface in the product, and every surface is in this template.

  • Traffic

    What is actually happening at the edge, second by second.


    • Request explorer

      Filter 30 days of wakes by method, status, endpoint, consumer, key or region.

    • Response inspector

      Headers, body, timing waterfall and the wake ID your support team can quote back.

    • Endpoint health

      p50 / p95 / p99, error rate and throughput per endpoint, sorted by whatever is hurting.

    • Live tail

      A rolling stream for the twenty minutes around a deploy.

    • Geography

      Latency split by edge region so you know whether it is you or the distance.

  • Reliability

    Turning a spike into an owner, a cause and a fix.


    • Error attribution

      Every non-2xx grouped by code, endpoint, consumer and deploy.

    • Replay

      Re-run any captured request against staging and diff the response.

    • SLO tracking

      Availability and latency objectives per endpoint with burn-rate alerts.

    • Deploy markers

      Charts annotated with the release that shifted the line.

    • Anomaly watch

      A quiet statistical baseline that pages you only when the shape genuinely changes.

  • Access

    Keys, scopes, quotas and the audit trail underneath them.


    • Scoped API keys

      Per-environment keys with explicit scopes and a visible last-used time.

    • Rotation with grace

      Issue the replacement, keep both valid for a window, revoke on schedule.

    • Rate limits

      Defaults per plan, overrides per consumer, headers your SDKs already understand.

    • Consumer directory

      Every integration with its plan, quota, error rate and owner.

    • Audit log

      Who changed which key, limit or webhook, from where, and when.

  • Delivery

    The half of an API that runs outbound.


    • Webhook endpoints

      Per-consumer endpoints with event-type subscriptions.

    • Signed payloads

      Timestamped HMAC signatures with a verification snippet in every SDK.

    • Retry and replay

      Exponential backoff, dead-letter after eight attempts, one-click manual replay.

    • Delivery stream

      Every attempt with its response code, duration and payload.

    • Endpoint health

      Automatic disablement of endpoints that have returned 410 for a week.

  • Developer experience

    What your consumers touch before they ever talk to you.


    • Hosted documentation

      Concepts, guides, quickstart and a reference that is generated, not written.

    • API playground

      Authenticated calls against sandbox fixtures, straight from the docs page.

    • Seven SDKs

      TypeScript, Python, Go, Ruby, PHP, Java and Rust with matching examples.

    • Copyable examples

      Language tabs on every snippet, with the consumer's own key pre-filled.

    • Changelog feed

      An RSS feed and a webhook so integrations hear about changes first.

  • Operations

    The things that make a platform team trust a platform.


    • Status page

      Component-level health with a 90-day history and subscribable incidents.

    • Data residency

      US, EU and AP processing regions, chosen per project.

    • Redaction rules

      Field-level rules applied at the edge before capture.

    • Retention control

      7, 30 or 90 days, set per environment.

    • Export

      Stream wakes to S3, BigQuery, Snowflake or your own object store.

How it works

One hop at the edge. Nothing in your hot path.

Flintwake runs as a lightweight edge collector in front of your API, or as a sidecar beside it. It observes, redacts and forwards — it never becomes the thing that has to be up for your API to answer.

  • Fails open: if the collector cannot write, your request still answers.
  • No proxying of request bodies to a third region.
  • Every capture rule is versioned and reviewable in Git.
  1. 01

    Observe

    The collector reads the request and response as they pass. Median added latency is under 2ms.

  2. 02

    Redact

    Field rules strip secrets and personal data before anything leaves your network boundary.

  3. 03

    Capture

    The wake is written to your chosen region with your chosen retention. Failures fail open.

  4. 04

    Resolve

    Explore, attribute, replay and alert — then push the result into the tools your team already uses.

Customers

What changed for the teams using it.

  • We used to close API support tickets with an apology. Now we close them with a wake ID and the exact line of the payload that was wrong. Average time to resolution went from four days to under an hour.
    Iris CalderStaff engineer, Northbank Payments
  • The consumer view is the part nobody else ships. Seeing our p95 split by integration told us in an afternoon what six months of service dashboards had not.
    Devan RouxHead of platform, Halyard Retail
  • Replay paid for the whole contract. We caught a settlement regression in staging by replaying eleven thousand production requests against the release candidate.
    Mireille OkaforPrincipal SRE, Cedarlift Logistics
Read the full customer stories

Point a collector at your API. See the first wake in four minutes.

No agent in your hot path, no schema migration, no sales call. Install the collector, send one request and the console fills in.

All metrics, customers, incidents and endpoints in this template are fictional demonstration data.