kubbi
kubbi is a managed claim-check API that hands AI agent payloads between systems via short-lived, single-use claim URLs.
kubbi solves a narrow, real problem well: getting bytes from one agent to another without leaking them into channels built for control flow. The free tier is usable for prototyping and $19/month Pro is honest pricing for moderate scale. Its real edge is server-enforced burn-after-read plus manifest preview applied to agent-shaped surfaces (MCP tools, A2A side-channel, SDKs) that S3 presigned URLs and raw webhooks don't match. It's a poor fit if you need streaming, persistence, or consumer-side access control — this is single-shot, URL-token delivery and nothing more. If you want durable object storage, stay with S3; if you want ordered replayable delivery, stay with SQS or Kafka.
Verified 2h ago · liveness 71/100 · cite: rightaichoice.com/tools/kubbi
- Developers building multi-agent systems that need secure payload handoffs between agents
- Teams passing payloads across vendor or organizational trust boundaries without sharing storage credentials
- MCP server or A2A users who need a side-channel for bytes while the message carries control flow
- Webhook receivers that want fast notifications without megabytes sitting in gateway logs
- Real-time streaming or low-latency data transfer — kubbi is single-shot payload delivery
- Long-term storage or durable persistence — every kubbi is designed to expire, burn, or be deleted
- Workflows needing consumer-side authentication or granular access control — the claim URL is the only credential
We scan live Reddit threads, YouTube comments, X posts, G2 reviews and other communities — and hand you an honest verdict in under a minute.
- Honest verdict, not marketing
- Real pros & cons from real users
- Attributed quotes with receipts
3 free scans · no card needed
Skip kubbi if you need streaming, durable storage, or consumer-side identity checks — its payload caps top out at 256 KB (25 MB packages) and delivery is single-shot, URL-token only.
Hitting your tier's daily kubbi count or active-kubbi cap returns a 429, forcing an upgrade to Pro ($19/mo) or waiting for the rolling 24-hour window to clear.
Free covers prototyping and low-volume agent handoffs; Pro at $19/month fits small teams and moderate production traffic; Enterprise is quoted for organizations that need 500 kubbis/day, 256 KB payloads, and custom SLAs. Cheaper than standing up your own KMS-plus-expiry-job stack; more expensive than an S3 bucket you already pay for — justify it on the trust-boundary and burn-after-read defaults, not on storage cost.
In short
kubbi — kubbi is a managed claim-check API that hands AI agent payloads between systems via short-lived, single-use claim URLs. Best for Developers building multi-agent systems that need secure payload handoffs between agents, Teams passing payloads across vendor or organizational trust boundaries without sharing storage credentials, MCP server or A2A users who need a side-channel for bytes while the message carries control flow. Free to start; paid plans from $19/mo.
What people actually say about kubbi — is it worth it?
We ran a structured research pass across product reviews, community discussions, and post-purchase forum threads to surface the patterns vendors won't publish themselves. Below: the recurring strengths, the hidden costs people mention most, and the cohort that consistently regrets adopting this tool.
10 mentions across 1 source (YouTube) · researched Aug 24, 2026.
Average across the 1 source that answered — each source counts once, not each post.
- +Server-enforced burn-after-read prevents accidental payload leaks
- +Short TTLs reduce window for unauthorized access
- +AES-256-GCM encryption at rest with per-payload IV
- +Multi-file bundles under one claim URL simplify complex handoffs
- +No consumer auth needed simplifies OPA handoff flows
- −No community feedback or case studies yet — unproven in production
- −Free tier TTL capped at 2 hours, limiting long-running workflows
- −Claim URLs are bearer tokens — interception means data theft
- −Payload size caps (16-256 KB) may be too small for many use cases
- −No consumer authentication means anyone with URL can claim payload
- • No public info on overage fees — likely require upgrading plans for higher usage
- • Potential extra latency from network round-trips to kubbi's servers
- • If you need consumer auth, you'll need to build it yourself on top
Viability Score
How well maintained and how widely used is kubbi? Built from what the vendor actually publishes (docs, changelog, tutorials, integrations, pricing), whether the site is live, and how much real users discuss it. How we calculate this
Last calculated: October 2026
How we score →Key Features
- Server-enforced burn-after-read deletes the payload when the retrieval limit is hit
- TTL expiry configurable from 1 minute up to the per-plan maximum, with short defaults
- AES-256-GCM encryption at rest with per-payload IV and auth tag
- Manifest preview shows file names, sizes, and types before claiming
- Multi-file packages delivered under a single claim URL
- Producer-side inspect() and delete() for early cleanup
- TypeScript SDK with KubbiClient.send() and sendFiles(), plus static claim and inspect
- Python SDK with sync and async clients, plus standalone claim() and inspect() functions
- REST API over HTTPS — Bearer auth for producers, claim URL token for consumers
- MCP server exposing six native tools: kubbi_send, kubbi_send_files, kubbi_claim, kubbi_inspect, kubbi_get, kubbi_delete
- Consumer claims with the URL alone — no API key or account required
- Three terminal states (expired, burned, deleted) wipe the row and overwrite ciphertext on storage
- Per-API-key rate limiting and rolling daily quota enforcement with 429 responses
- Capability URL pattern: short-lived, unguessable reference carries no payload bytes
- Inspect a kubbi's manifest without consuming the retrieval count
About kubbi
kubbi is a managed claim-check service built for AI agent handoffs. Instead of pushing files, JSON, or multi-file bundles through a queue, webhook, MCP tool result, or A2A message, the producer stores the payload with kubbi once and gets back a claim URL. Your existing channel carries only that URL; the consumer redeems it for the bytes. Producers authenticate with an API key, consumers claim with the URL alone — no account, no shared storage credentials — which is what makes it work across trust boundaries and between vendors. The behaviors are server-enforced rather than flags you remember to set: burn-after-read (hit the retrieval limit and the payload is gone), short TTL expiry measured in minutes to days, AES-256-GCM encryption at rest with a per-payload IV and auth tag, and manifest preview so a consumer can see file names, sizes, and types before spending a retrieval. Multi-file packages travel under one claim URL, producers can inspect or delete early, and every kubbi ends in one of three terminal states — expired, burned, or deleted — that wipe the row and overwrite ciphertext on storage. Surfaces cover the common runtimes: TypeScript and Python SDKs (sync and async), a REST API over HTTPS, and an MCP server exposing six native tools (kubbi_send, kubbi_send_files, kubbi_claim, kubbi_inspect, kubbi_get, kubbi_delete). It slots alongside SQS, Kafka, webhooks, and A2A rather than replacing them. Reach for kubbi when payloads cross an organizational boundary, need atomic delivery, or are too sensitive to sit in logs and dead-letter queues. Compared with S3 presigned URLs or a self-built claim-check service, you trade a little control for defaults that match agent traffic — bucket credentials never leave your side, and there is no KMS policy or expiry job to maintain.
Behind the Verdict
kubbi's pitch is narrow by design and it's better for it. It does not try to replace your queue, your webhook, or your object store — it removes the payload from all three. The producer calls send() or sendFiles() with a TTL and an optional max_retrievals, gets a claim URL back, and drops that URL into whatever channel already connects the two agents: an SQS message, an MCP tool result, an A2A message, a webhook body. The consumer calls claim() with the URL and gets the bytes. No account, no shared bucket credentials. That is the entire product, and that is the point. What's genuinely good: the security-relevant behaviors are server-enforced rather than client flags. Burn-after-read fires when max_retrievals is hit, TTL expiry fires on the clock, and each kubbi terminates in exactly one of three states (expired, burned, deleted) that wipe the row and overwrite ciphertext before the status updates. AES-256-GCM with a per-payload IV and auth tag is applied at ingest, so the database never holds plaintext. The manifest preview is an underrated touch — a consumer can inspect file names, sizes, and types before spending the retrieval, which matters when max_retrievals is 1. The surfaces are shaped right. TypeScript and Python SDKs cover the two runtimes most agent code ships in, the REST API is a clean fallback, and the MCP server exposes six native tools so an MCP-capable agent can send, inspect, claim, and delete without any glue code. The file-package path (config, data, instructions, attachments under one claim URL) is the case S3 presigned URLs handle most awkwardly. Where it does not fit: this is single-shot delivery, full stop. No streaming, no replay, no fan-out, no durable storage. Payload caps are modest even on paid tiers — 256 KB per payload and 25 MB per package on Enterprise, well short of model artifacts or media. The consumer has no authentication beyond URL unguessability, so anyone who gets the URL can claim the payload; that is the deliberate trade, but it means kubbi is the wrong place for anything you would not put behind a short-lived single-use link. TTL is capped per plan (2 hours on Free, 2 days on Pro, 7 days on Enterprise), daily creation quotas bite at high volume, and the free tier's 16 KB payload / 1 MB package limit is fine for config files and test fixtures but not for real datasets. If your handoff crosses a trust boundary and fits in a few hundred kilobytes, kubbi's defaults will save you a weekend of IAM and expiry-job work. If it doesn't, kubbi is the wrong tool and the docs say so.
Researching kubbi? Get your full AI stack in 60 seconds.
Free, no signup — tell us your goal and get tools matched to your budget & existing stack.
Real-world workflow fit
Concrete scenarios for the personas kubbi actually fits — and what changes day-one when you adopt it.
Your MCP server produces a sensitive config bundle that a partner vendor's agent must pick up. Instead of emailing credentials or standing up a shared S3 bucket, your server calls sendFiles() with ttlSeconds: 3600 and maxRetrievals: 1, and returns the claim URL as the MCP tool result.
Outcome: The partner's agent inspects the manifest to confirm file names and sizes, then claims the bundle with the URL alone — no shared storage, no credentials traded, and the payload self-destructs on retrieval.
A 1 MB JSON payload exceeds the SQS 256 KB inline cap. You park the payload in kubbi with a 2-day TTL on Pro, and push only the claim URL and an ID through the queue.
Outcome: The consumer service calls claim() when it dequeues the message, the 256 KB cap stops mattering, and sensitive fields stop lingering in dead-letter queues or gateway logs.
An agent finishes a code-review task and needs a person to sign off. It creates a kubbi with maxRetrievals: 1 and a short TTL, then posts the claim URL to the reviewer's channel.
Outcome: The reviewer inspects the manifest without burning the retrieval, downloads the artifact exactly once, and the payload is wiped — no artifact left sitting in Slack or a shared drive.
Use Cases
- Transfer sensitive configuration files between AI agents without exposing them in queue or webhook logs.
- Bundle a multi-file package (config, data, instructions, attachments) for a downstream agent to claim exactly once.
- Pass large payloads through A2A messages without hitting size limits or encrypting inline.
- Implement a burn-after-read handoff for one-shot agent tasks like file processing or code review.
- Decouple payload delivery from control flow in agent orchestration pipelines using webhooks or MCP tool results.
- Enable human-in-the-loop review by sharing a claim URL that disappears after the reviewer inspects it.
- Cross-vendor MCP handoff where your MCP server returns a claim URL and another vendor's agent claims the payload.
- Queue claim-check: pass an ID through SQS or Kafka while the payload sits in kubbi, sidestepping the 256 KB message cap.
Limitations
- Payload size is limited even on paid plans (max 256 KB payload and 25 MB package on Enterprise).
- Daily kubbi creation quotas constrain high-volume usage unless you move to Enterprise (500 kubbis/day).
- The consumer has no authentication, so anyone with the URL can claim the payload — security relies on URL unguessability and a limited retrieval count.
- TTL is capped per plan (Free: 2 hours, Pro: 2 days, Enterprise: 7 days) with a 1-minute minimum.
- No built-in consumer identity verification, no fan-out to multiple consumers, and no ordered or replayable delivery.
as of 2026-09-22
Verification history
We have re-verified kubbi 11 times since . Each pass re-reads the vendor's own pages and re-checks every listed field against that evidence; passes where nothing had changed are marked as such.
- — re-checked, vendor evidence unchanged
- — re-checked, vendor evidence unchanged
- — re-verified summary, description, our verdict, our analysis, pricing model, pricing tiers, features, integrations, who it suits, who should skip it
- — re-verified summary, description, our verdict, our analysis, pricing model, pricing tiers, features, integrations, who it suits, who should skip it
- — re-verified summary, description, our verdict, our analysis, pricing model, pricing tiers, features, integrations, who it suits, who should skip it
- — re-verified summary, description, our verdict, our analysis, pricing model, pricing tiers, features, integrations, who it suits, who should skip it
Showing the 6 most recent of 11 verification passes.
Free to cite with attribution — this page re-verifies continuously.
12-month cost
Project the real annual outlay, including the implied monthly cost when only an annual tier is published.
Vendor list price only. Add-on usage, seat overages, and contract minimums are surfaced under Hidden costs & gotchas.
Plans compared
For each published kubbi tier: who it actually fits, and what it adds vs. the previous tier. Cross-reference the cost calculator above for projected annual outlay.
Free
$0/month
Ideal for
Individual developers prototyping an agent handoff or running a low-volume side project — no credit card required.
What this tier adds
Starting tier: 20 kubbis/day, 16 KB payloads (1 MB packages), 2-hour TTL, 5 retrievals, 20 req/min.
Pro
$19/month
Ideal for
Small teams and professionals running production agent handoffs at moderate volume who have outgrown the Free caps.
What this tier adds
Adds 100 kubbis/day, 64 KB payloads (5 MB packages), 2-day TTL, 25 retrievals, 5 API keys, 100 req/min, and priority support.
Enterprise
Custom
Ideal for
Organizations with custom requirements — compliance-bound teams needing SSO, dedicated infrastructure, and higher quotas.
What this tier adds
Adds 500 kubbis/day, 256 KB payloads (25 MB packages), 7-day TTL, 100 retrievals, 25 API keys, 500 req/min, plus custom SLAs and dedicated support.
Where the pricing makes sense
The company stage and team size where kubbi's pricing actually pencils out — and where peers do it cheaper.
Free covers prototyping and low-volume agent handoffs; Pro at $19/month fits small teams and moderate production traffic; Enterprise is quoted for organizations that need 500 kubbis/day, 256 KB payloads, and custom SLAs. Cheaper than standing up your own KMS-plus-expiry-job stack; more expensive than an S3 bucket you already pay for — justify it on the trust-boundary and burn-after-read defaults, not on storage cost.
Setup time & first value
How long it actually takes to get something useful out of kubbi — broken out by persona, not the marketing-page minute.
Solo developer: under two minutes to first kubbi, per the quickstart — install the SDK, get an API key, call send(), and share the claim URL. Team rolling out across services: a few hours, mostly spent deciding TTL and retrieval defaults per handoff pattern and wiring the claim URL into existing queues, webhooks, or MCP tool results. No infrastructure to provision.
Switching to or from kubbi
How to bring data in from common predecessors and how to get it back out — written for the switcher, not the buyer.
- →From S3 presigned URLs: replace the bucket-and-presign flow with send()/sendFiles() and pass the claim URL instead; kubbi handles encryption, expiry, and multipart bundling.
- →From raw webhooks with inline payloads: move the bytes into kubbi, send the claim URL in the webhook body, and have the receiver call claim() only if it needs the payload.
- →From a self-built claim-check service: retire your KMS policy, expiry job, and manifest code — kubbi enforces burn-after-read, TTL, and manifest preview server-side.
- →From inline queue messages (SQS, Kafka): keep the queue for control flow, park the payload in kubbi, and ship the claim URL alongside the message ID.
- ↗To S3 with presigned URLs: if you need durable storage, larger objects, or long-lived links, upload directly to a bucket and hand out presigned URLs instead of claim URLs.
- ↗To a queue with inline payloads: if payloads fit under 256 KB and you want ordered replayable delivery, push the bytes directly through SQS or Kafka.
- ↗To a self-hosted claim-check service: if you need consumer authentication, per-consumer authorization, or audit controls kubbi does not expose, run it on your own infrastructure.
- ↗To a streaming transport: for real-time or high-frequency data transfer, move to a socket, gRPC stream, or event bus rather than single-shot claim URLs.
Integrations
Resources & Guides
Tutorials & Learning
YouTube returned 6 videos for “kubbi”, and we withheld 6: 6 could not be judged, because “kubbi” is a single word that other videos use for other things. We are showing none, because we could not prove any of them are about kubbi.
Official links
Featured Head-to-Head Comparisons
Kubbi vs Spider Cloud
Spider Cloud and kubbi solve entirely different problems: Spider Cloud fetches external web data for AI agents, while kubbi shuttles internal payloads between agents. Neither is a substitute for the other. Choose Spider Cloud if you need to scrape, crawl, or search the web for RAG; choose kubbi if you need a secure, ephemeral handoff mechanism within your multi-agent system. They can even complement each other in a single pipeline.
Kubbi vs Temporal Ai
Temporal AI and kubbi address different problems: Temporal is a full-featured orchestration engine for durable, fault-tolerant workflows, while kubbi is a focused claim-check service for secure payload handoffs. Choose Temporal if you need reliability, state persistence, and multi-step orchestration; choose kubbi if your main challenge is passing sensitive payloads between agents without polluting channels.
Kubbi vs Presto Voice
Presto Voice and kubbi serve entirely different domains—Presto automates drive-thru ordering for QSR chains, while kubbi provides secure payload handoff for AI agent architectures. If you run a multi-location QSR aiming to boost revenue via voice AI upselling, Presto Voice is the clear choice. For developers needing a managed claim-check service with encryption and TTL for agent-to-agent data transfer, kubbi is the pragmatic pick. Neither tool competes directly; your workflow dictates the winner.
Popular in Agent Memory & Runtimes
Frequently Asked Questions
Categories
Best-of guides
Topics
Used kubbi? Help shape our editorial sentiment research.