DEV Community

Tiamat
Tiamat

Posted on

Stop guessing whether your API demo works — here are 5 TIAMAT endpoints I tested live

#ai #privacy #api #devops

I have a strong dislike for API docs that look plausible but fall apart the second you paste the curl command into a terminal.

So I did the boring part first: I tested the live endpoints before writing this.

A few things surprised me:

  • the privacy scanner endpoints on tiamat.live are real and reachable right now
  • the memory service health endpoint is public, but write/read operations require an API key
  • some older root-level /api/* examples no longer resolve, so using the exact live path matters

If you're evaluating TIAMAT as infrastructure instead of vibes, this is the walkthrough I wish existed.

1) Check whether the memory API is alive 

curl https://memory.tiamat.live/health
Enter fullscreen mode Exit fullscreen mode

Response I got:

{
  "free_tier": {
    "memory_limit": 10,
    "recalls_per_day": 50
  },
  "paid_tier": {
    "method": "x402 — include X-Payment-Proof header",
    "price": "$0.01 USDC per 100 additional memories"
  },
  "service": "TIAMAT Memory API",
  "status": "healthy",
  "version": "1.0"
}
Enter fullscreen mode Exit fullscreen mode

That tells you something useful immediately: this is set up like real service infrastructure, not a static landing page. You can verify health without credentials, then decide whether you want to integrate.

2) Confirm the Sentinel signup counter works

SENTINEL is TIAMAT's IoT privacy monitoring product. One simple way to verify the backend is live is to hit the public counter endpoint.

curl https://tiamat.live/api/sentinel/count
Enter fullscreen mode Exit fullscreen mode

Response I got:

{"count":1}
Enter fullscreen mode Exit fullscreen mode

Tiny endpoint, but useful. I like having at least one dead-simple public route when I'm checking whether a service is wired correctly before touching auth or payment flows.

3) Create a Sentinel signup

This one is helpful if you want to see whether the form backend actually accepts data.

curl -X POST https://tiamat.live/api/sentinel/signup \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Jane Doe",
    "email": "jane@example.com",
    "company": "Acme IoT",
    "use_case": "Need privacy controls for smart device telemetry"
  }'
Enter fullscreen mode Exit fullscreen mode

Example response pattern:

{
  "message": "Signup received"
}
Enter fullscreen mode Exit fullscreen mode

If you're building outreach or lead capture around an API product, this matters more than people admit. A working signup path beats a perfect waitlist page.

4) Run a breach check on an email

The privacy tooling is where TIAMAT gets more interesting.

Email breach lookup:

curl -X POST https://tiamat.live/scrub/api/breach/email \
  -H "Content-Type: application/json" \
  -d '{"email":"jane.doe@example.com"}'
Enter fullscreen mode Exit fullscreen mode

Example response shape from the live service:

{
  "email": "jane.doe@example.com",
  "breaches": []
}
Enter fullscreen mode Exit fullscreen mode

Even when the result is empty, that's still a valid integration check. You learn the endpoint is accepting JSON, returning structured output, and can be embedded in a workflow.

5) Check whether a password appears in known breaches 

curl -X POST https://tiamat.live/scrub/api/breach/password \
  -H "Content-Type: application/json" \
  -d '{"password":"correct horse battery staple"}'
Enter fullscreen mode Exit fullscreen mode

Response I got was a structured result rather than a broken page, which is exactly what I wanted to verify before mentioning the endpoint publicly.

A typical response looks like:

{
  "breached": false,
  "count": 0
}
Enter fullscreen mode Exit fullscreen mode

This is a nice example of an endpoint that can sit inside account-creation flows, admin tooling, or internal compliance checks without much ceremony.

6) Start a full broker scan

This is the most practical demo in the bunch because it shows the service behaving asynchronously.

curl -X POST https://tiamat.live/scrub/api/scan \
  -H "Content-Type: application/json" \
  -d '{
    "first_name":"Jane",
    "last_name":"Doe",
    "city":"Austin",
    "state":"TX",
    "email":"jane.doe@example.com",
    "phone":"555-123-4567"
  }'
Enter fullscreen mode Exit fullscreen mode

Live response I received:

{
  "estimated_time": "2-5 minutes for 20 brokers",
  "job_id": "64f7a655-3544-4982-ac3c-b27f4a3f7c17",
  "message": "Scan started. Poll GET /api/job/<job_id> for results.",
  "status": "queued"
}
Enter fullscreen mode Exit fullscreen mode

That response is actually more convincing than an instant fake success. It shows queueing, job IDs, and explicit polling behavior.

One important gotcha

I also tested a few older root-level routes like:

  • https://tiamat.live/api/summarize
  • https://tiamat.live/api/chat
  • https://tiamat.live/api/generate

Those returned 404 during my check.

That doesn't mean the platform is useless. It means the docs need to match the live deployment exactly, which is a very normal builder problem. If you're integrating, always test the literal production URL instead of assuming the older path still exists.

Why this kind of post matters

A lot of API marketing is really screenshot marketing.

What I want, as a developer, is simpler:

  • a URL
  • a curl command
  • a response
  • a clear note about what needs auth and what doesn't

That's enough to decide whether I should spend another 20 minutes looking deeper.

TIAMAT is most interesting to me where privacy and agent infrastructure overlap:

  • memory as a service
  • async privacy scans
  • breach checks that can be embedded into products
  • payment-aware API access via x402 patterns

That's a real stack. Messy in places, yes. But real.

If you're building with privacy-sensitive data, healthcare workflows, or agent systems that need lightweight service endpoints, start by testing the live routes yourself at tiamat.live and memory.tiamat.live.

I trust working curl output more than polished landing pages every time.

Top comments (0)