For teams shipping agent-driven products

API access that treats every agent as its own identity.

Mint a separate, revocable key for every agent — with per-key audit trails — and publish a machine-readable OpenAPI doc each agent can read, re-sync, and trust.

Request early access

otaviovacari@usp.br

Built for agent-driven traffic

Most APIs were designed for humans and break under iterative, autonomous agents. Two of those gaps are already first-class concerns in Redirector.

Every agent gets its own identity

The challenge

Today only ~22% of teams treat agents as independent identities; the rest share API keys or human user accounts, making audit and granular revoke impossible.

How Redirector solves it. Mint N keys per (API, consumer) — prod, staging, backfill-2026 — each with its own label, status, and revoke timestamp. Every proxied call is attributed to a specific key, and revoking an access request cascade-revokes every key under it.

Docs agents can actually read — and re-read

The challenge

Ambiguous, drifting documentation is the #1 cause of agent hallucination on real APIs: invalid calls, missing metadata, and stale endpoint contracts.

How Redirector solves it. Every imported API publishes a normalized OpenAPI 3.x document at /mappings/{id}/openapi with a uniform X-Api-Key security scheme. Owners re-sync from the source URL anytime; the platform surfaces new, changed, and removed operations plus lint findings so agents never silently drift.

For the API owner

You run the upstream API and decide who reaches it. Each card is a user story you can ship against.

Gate access with API keys

As an API owner,

I want to mint and revoke keys per developer or team and forward trusted headers to my backend.

So that I control who reaches my API without exposing internal credentials to clients.

See usage and traffic

As an API owner,

I want per-mapping request logs, status codes, duration, and rolled-up stats.

So that I can answer “who called what?”, debug incidents, and spot abuse without building dashboards first.

Own the access workflow

As an API owner,

I want developers to request access and for me to approve or deny—and when I revoke access, their keys retire with it.

So that onboarding stays deliberate and offboarding does not leave stray credentials.

Publish one stable entry point

As an API owner,

I want a single public proxy URL to my upstream base, with optional OpenAPI-based blocking of undocumented paths or methods.

So that partners integrate against a stable surface and I can narrow what reaches my servers when I choose to.

For the API customer

You integrate with an API that is exposed through Redirector. Same story format—written from your seat.

Call the API with a key

As an API customer,

I want to send X-Api-Key on each request to the public proxy URL.

So that I integrate like a normal HTTP client without bespoke login handoffs from every API owner.

Discover and request access

As an API customer,

I want to browse the catalog, submit an access request, and receive keys after the owner approves me.

So that I can onboard to partner APIs through one predictable path instead of ad-hoc email threads.

Trust what I shipped

As an API customer,

I want request history and stats for the keys I hold.

So that I can debug integrations and show traffic evidence to my team without reverse-engineering logs from the owner.