The Partner plan
Let your customers approve AI actions.
Before your agent refunds money, sends a message or deletes data, Pushary asks the customer for approval. They answer on their phone or in their browser. Your agent gets the result, with a record of the decision.
Example notification: your customer taps Approve or Deny on their device.
@pushary/server · @pushary/ai-sdk · @pushary/eve · pip install pushary
How it works
Your agent asks. Your customer answers.
Add one approval step before the action runs. Pushary handles reaching the person and returning their answer.
01
Connect your customer
Send them an invite link from your product. They connect the Pushary app or a supported browser. No Pushary account or subscription for them.
02
Ask before the action
Your server sends the question to that customer: ‘Approve this refund?’ Your code waits for an answer before moving money or changing data.
03
Continue only with approval
Approve lets your code continue. Deny or no answer keeps the action blocked. You can look up who answered and when.
Try one approval before integrating everything.
Create your account, start your trial at checkout, then add your product name and connect a device. Onboarding gives you an API key and an example request to try. You can create your account on your phone and continue setup on your computer.
Start your 3-day Partner trialCard required. Trial and paid allowances are shown below.
Offres Partner
Choisissez la capacité adaptée à votre produit. Les abonnés Partner existants conservent leurs conditions.
Premier essai par espace : 100 clients connectés et 100 demandes humaines pendant trois jours. Les quotas payants commencent avec la période facturée. Les nouvelles tentatives et la livraison sur plusieurs appareils ne comptent pas en plus. Les notifications informatives ne sont pas incluses. Aucun dépassement facturé automatiquement.
Where they answer
Your users answer wherever they already are
They never make a Pushary account, never hold an API key, and never get a bill from us.
Answer once and it settles everywhere. Approve on a phone and the browser notification closes itself and the open page says so.
- Their phone
- iOS and Android. One tap on the connect link and decisions arrive from then on.
- The lock screen
- Approve and Deny are buttons on the notification itself. They never open the app to answer.
- Their browser
- Push on Chrome, Firefox, Edge, Android and desktop Safari. On iPhone this needs the site installed to the Home Screen first, so the app is the better route there.
- A decision page
- A link that works anywhere, carries your brand, and needs no login. This is where a notification lands when it is tapped.
- Your own channel
- Ask for a signed link and deliver it yourself, over email or anywhere else you already reach them.
Ask for approval only when it matters
A rule reads the amount, so you write "refunds over $1,000 need approval" instead of "all refunds need approval".
Allow small refunds automatically, ask a person about larger ones, and block amounts you never want the agent to refund.
$42 runs on its own. $4,200 asks your customer first. $40,000 never happens. An action with no rule asks a person, so a gap is never a yes.
View the rules and API example
refund.create amount < 100 allow
refund.create amount >= 1000 require_approval
refund.create amount >= 10000 denyPOST /api/v1/server/authorization-rules
{
"toolPattern": "refund.create",
"effect": "require_approval",
"conditions": [
{ "parameter": "amount", "operator": "gte", "value": 1000 }
]
}- allow
- A rule of yours names the action and permits it. The agent continues. Nobody gets a message. The record names the rule that decided.
- deny
- A rule refuses the action. The agent stops and gets a reason in plain text, so the model can act on it instead of retrying.
- requires_human
- Two things send the decision to a person: your rule asks for one, or no rule matches the action. An empty policy does the same. A rule you have not written yet never allows an action.
The strictest rule wins, so the order you write them in never changes the answer. The rule decides whether to ask. You decide who gets asked.
The call
Two calls, and most actions never reach a person
The same code works for one customer or a hundred thousand. You point at them with the id you already have.
The rules above decided this one. The rest of your code is unchanged.
import { createPusharyServer } from "@pushary/server"
const px = createPusharyServer({ apiKey: process.env.PUSHARY_API_KEY! })
// In your onboarding flow, show this link to the signed-in customer.
// They must open it and connect the app or a supported browser.
const { universalLink } = await px.enroll(customer.id)
// Rules answer first. This one is over your $1,000 threshold.
const decision = await px.authorize({
toolName: "refund.create",
toolTarget: "order_4471",
externalId: customer.id,
parameters: { amount: 4200 },
question: "Approve a $4,200 refund for order #4471?",
})
if (!decision.approved) throw new Error(decision.reason)
await issueRefund()You always get the same answer back
Check approved before running the action. Use the decision ID to look up the result or resume a durable workflow.
// $42. Your rule allowed it. Your customer was never contacted.
{ approved: true, resolvedBy: "policy", reason: "Allowed by policy rule refund.create." }
// $4,200. Your require_approval rule sent it to your customer. They tapped Approve.
{ approved: true, resolvedBy: "human", reason: "A person approved it." }
// $4,200, and nobody answered inside the window.
{ approved: false, resolvedBy: "human", reason: "Nobody answered, so this was not approved." }If the SDK stops waiting without approval, it returns approved: false. Keep the action blocked; the decision may still be pending. Save its ID to resume from polling or a verified callback. A rule you have not written never silently allows the action.
You can build this. Here is what it is.
Each part is easy on its own. Together they are a distributed systems project sitting in the middle of the product you meant to ship.
- Deciding
- A policy evaluator that resolves conflicting rules the same way every time, treats a parameter it cannot read as a reason to ask, and moves a threshold without a deploy.
- Reaching the person
- A path to a phone that works away from a desk, with a fallback when the first channel fails.
- Connecting a user
- An enrollment flow for someone with no account, who has never heard of your vendor, and who gives it one tap.
- Waiting
- A wait that holds across a deploy or a crash. An in-memory promise dies with the process.
- Timing out
- A timeout that denies rather than assumes yes, and a way to tell the two apart afterwards.
- The record
- A store you can query: who you asked, what they saw, what they chose, when.
- The page they answer on
- A decision page carrying your brand, because your customer is the one looking at it.
Built for your customer, not your engineer
The person who taps Approve has never heard of Pushary, and never needs to.
Your users, not just you
The externalId is your own id for the end user. Send them a connect link. It opens the Pushary app, which puts Approve and Deny on the lock screen. No account, no key, no bill on their side.
Durable waits that fail closed
The SDK returns approved: false when its wait ends without approval, but the decision can still be pending. Save its id and the proposed action so a restarted worker runs only after an explicit approval.
A decision page under your brand
Your customer is the one answering, so the page carries your product name and your logo. Turn off the Pushary line in settings and our name is not on it at all.
Every answer saved, and sent to your server
We save every answer, and you can export it. When someone answers, we tell your server with a signed webhook.
What gets asked
Anywhere an agent needs a person
The same call, the same shape back. What changes is the question.
Money
Approve a $4,200 refund?
Communication
Send this proposal to the customer?
Destructive
Delete these 2,400 records?
Operational
Deploy this release to production?
Who embeds this
Where the approver is somebody else
The rules and the SDK do not change. Only whose phone the exceptions reach.
You ship an AI agent to customers
Refunds, outbound messages, deletions, anything that moves money. Pushary asks the customer whose money is on the line and returns their answer to your agent.
You build agents for clients
Every client build repeats the same approval plumbing, and it is never the part you quoted for. Embed Pushary once and it leaves the estimate for good.
You run a platform other people build on
Today each of your users builds the approval step alone. Add Pushary once, and every user can approve from their phone. You build nothing new.
One product, your own customers: this is the plan. Several client workspaces, or a platform other people build on, is a different shape. Tell us the shape and we will price it with you.
Questions, answered
How do I add human approval to an AI product my customers use?
Do my end users need a Pushary account or an app?
Who decides which of my customers gets asked?
Does this mean more interruptions for my customers?
How is this different from a notification API like Knock or Novu?
How is this different from HumanLayer?
What happens if the person never answers?
What is included in the Partner trial and plans?
Which frameworks does this work with?
I build agents for several clients. Do I need one plan each?
Does this cover the EU AI Act human oversight requirement?
Most actions should never reach a person.
Write the rules for the ones that should. Your agent gets allow, deny, or the answer of the customer whose money it is. Every answer is saved.
Start your 3-day Partner trialTry it live, no signupUsing AI agents yourself? Get their questions on your phone or your Mac, and answer from either one. See the agent plans.