Stop the runaway integration or agent, not the customer.

When one customer's AI agent or sync job loops, an account-wide limit or a suspended key stops their billing, scheduling or accounting integrations too. Your support team then has to explain why a customer who did nothing wrong lost their whole integration.

Free for your customers still costs you: every call uses your compute and any paid services behind it, and a runaway or abused key can run up that bill for everyone.

Give each integration or agent its own agent key and allowance. Ordainer Cap says no to the one that's over, before your API does the work, and that deny doesn't cut off the customer's other integrations.

One agent key per integration or agent. You issue an agent key to each integration or agent, tied to one customer and one plan. A plan is a monthly cap on allowed uses, for one tool or for all your tools. Nothing is billed to your customers.

Your handler asks first. Before any work, your code calls decide() with the caller's agent key and the tool name. We answer allow or deny. On a deny in enforce mode, your handler doesn't run and the caller gets a plain message (a 429 when it's over its allowance). Denies don't count toward the cap.

Roll out in shadow mode. New plans you create start in shadow mode: we log what we would have blocked and block nothing. Switch to enforce in the console when the numbers look right, with no deploy unless your code pins the mode.

With our Node SDK (npm install ordainer) and Express:

const { Ordainer } = require('ordainer');
const ordainer = new Ordainer(); // reads ORDAINER_KEY and ORDAINER_BASE_URL

app.post('/api/sync', ordainer.middleware({
  tool: 'sync.run',
  apiKey: (req) => agentKeyFor(req), // your lookup: the agent key you issued to this integration or agent
}), syncHandler);

Each new decision writes one audit row, naming the integration or agent and its customer, with the reason. Export it as CSV or JSON when you need to show a customer what happened.

Our API is free. Is Ordainer Cap for us?

Yes, if one customer's integration or agent can run away. You set an allowance per agent key, and nothing is billed to your customers. A deny stops only that key. Ordainer Cap counts uses against a monthly allowance. It isn't a rate limiter, so keep your own rate limits for short bursts.

We already have a gateway and rate limits. Why add this?

Keep them. They limit how much traffic gets through. Ordainer Cap decides whether one integration or agent may do one piece of work, so you can say no to the one that's over its allowance without cutting off that customer's other integrations. Each new decision writes an audit row you can show the customer.

Is this rate limiting?

No. Your limits are counts per agent key: a monthly cap for one tool or for all your tools. Before the work runs, your handler calls decide() with the caller's agent key and tool name. We answer allow or deny, and each new decision writes one audit row. Keep your own rate limits for traffic spikes.

Does our traffic go through you?

No. The SDK sends only the agent key, the tool name and, if you set them, an idempotency key and a mode, never your payload. If we're slow or unreachable, the SDK stops waiting after a short timeout. By default it lets the call run, and you can set it to block instead. A clear answer from us, such as a deny, is followed in either setting.

What does it cost?

Beta teams get everything in the sandbox at no cost, whether or not you charge for your own API. No credit card needed, and nothing to cancel.