Coming from Kong

If you run Kong, Tyk or another gateway mainly to put API keys and rate limits in front of an API, and then bolt on a portal and billing, MicroAuth replaces that stack with one dependency in your app and one dashboard.

What changes

A gateway sits in the request path. Every call goes through it, so it is one more service to deploy, scale, secure and keep in sync with your routes.

MicroAuth doesn't proxy traffic. The SDK runs inside your API, keeps a cached snapshot of keys and limits in memory, and decides each request locally. Usage is reported in the background. If MicroAuth is briefly unreachable, known keys keep working from the cache.

	A typical gateway setup	MicroAuth
Where checks run	A proxy in front of your API	Inside your API process
Extra hop per request	Yes	No
Configuration	Services, routes, plugins, declarative files	A dashboard, and a platform API if you want one
Developer portal	A separate product or project	Included, with your branding and domain
Usage billing	A separate system	Included: credit, plans, Stripe and a ledger

Concept map

Kong	MicroAuth
Service and Route	Your own routes. Add Security(auth) to the ones that need a key
Consumer	Customer, which is always a team
key-auth credential	Customer API key (map_...), created by the customer on your portal
rate-limiting plugin	Requests a second in your defaults, a plan or custom limits
Monthly limits	Requests a month, the same three ways
acl groups for tiers	Monthly plans, public or private
Disabling a consumer	Suspend on the customer's page
Redis policy for cluster wide limits	redis_url in the SDK, see Redis
Admin API and decK	The platform API with a workspace API key
Developer portal	Your branded portal, included on every plan

Migrate in five steps

Launch the API

Follow the Quickstart up to the SDK secret key. Pick the pricing preset closest to what you charge today. You can change it at any time on the Pricing tab.

Recreate your tiers

Turn each tier into your default limits or a monthly plan with the same rate limit. For a handful of special accounts, use custom limits instead of a plan.

Accept both kinds of key for a while

MicroAuth issues its own keys, so existing Kong keys can't be imported. Run both during the move. Kong's key-auth reads the apikey header by default and MicroAuth reads X-API-Key, so they don't collide:

from fastapi import Header, HTTPException, Security
from microauth_fastapi import Customer, MicroAuth

auth = MicroAuth(app)

async def caller(
    customer: Customer | None = Security(auth.optional),
    apikey: str | None = Header(default=None),
) -> str:
    if customer is not None:
        return customer.id             # new key: limits and billing apply
    if apikey and is_legacy_key(apikey):
        return f"legacy:{apikey[:6]}"  # old key: your existing check
    raise HTTPException(401, "Missing API key")

auth.optional lets requests without a MicroAuth key through to your legacy check. A request that does send a MicroAuth key still gets every check.

Move your customers

Share your portal address, or invite people from the Customers tab with Invite. Each customer signs up and creates a key in seconds. To invite in bulk, call POST /api/v1/apis/{id}/customers/invite with a workspace API key.

Switch off the gateway

When legacy traffic drops to zero, replace caller with Security(auth) and remove the route from Kong. Your API now serves directly, with one less service in the path.

Questions people ask

Can a customer get around the checks? Only by getting around your own code. The SDK runs in your process, so it is as strong as your deployment. Rate limits are exact per process, and exact across processes once Redis is set. See where checks happen.

What happens if MicroAuth is down? Known keys keep working from the cached snapshot, and usage is queued and delivered later. See the FastAPI SDK guide for the exact rules.

Do I need FastAPI? No. The SDK API is three HTTP endpoints. See the HTTP API guide.