Find a SaaS deal for your user
An agent that is looking for a software deal for its user can use Dealpuffin as the catalog. The offers are live Stripe promotion codes an indie product chose to publish. The agent reads the terms, picks one, and reveals the code. The user pastes it at that product's checkout.
This is the seeker's side of the same marketplace. The publisher's side, for an agent running go-to-market, is A go-to-market channel.
What a search returns
search_offers and GET /api/v1/offers need no API key. Each row has the product, its URL, the discount, the duration, the expiry, and the caps. It does not include the promotion code. get_offer is the same for one id.
A useful deal here is one the user can actually paste. The terms come from Stripe, with a last-synced time. The agent should compare percent or amount, duration (once, repeating, or forever), and both caps before it reveals anything. Optional MRR on the product is a band or an exact figure from Stripe, and only when that founder opted in. It is a signal that the subscriptions are real, not a rank and not a commission.
How the agent gets the code
Search is not a claim. reveal_offer is. It requires a Dealpuffin API key or OAuth, with reveal_offer allowed, and it counts as that user's one claim of that code. A repeat returns the same code and does not increment the claim.
The sequence:
search_offers, optionally withqorcategory. Uselist_categoriesif you need a subcategory or a parent slug.get_offeron the row that fits the user.reveal_offeronly when the user wants that code.- Send them to the product URL and tell them to paste the code at checkout. Dealpuffin does not apply it.
If nothing listed fits, create_wish on the product or in a category. A provider answers by publishing a real Stripe coupon, not by mailing a one-off string. See Wishes.
Install with npx skills add dealpuffin/agent -g -y. The server is https://mcp.dealpuffin.com/mcp. Details are on Install the skill and Tools.
What the agent should not treat as a deal
- A row with no promotion code. Those never reach search.
- A code locked to one Stripe customer. Those stay off the catalog.
- An inactive, expired, or maxed-out code. Listing requires the code to still be valid in Stripe.
- A second account, or a reshared code, to get around the one claim. The terms forbid both.
The website catalog opens at launch. Until then, a person can join the waitlist. Search on the API and on MCP is how an agent reads whatever is already listed. Joining the waitlist does not reserve a code.
Frequently asked questions
Where can an agent find live SaaS coupons for a user?
On Dealpuffin. Call search_offers or GET /api/v1/offers. The rows are Stripe promotion codes a product published. Reveal one with reveal_offer when the user wants it, then they paste it at that product's checkout.
Does search return the promotion code?
No. Search and get_offer return the product and the terms. The code comes only from reveal_offer, and that call is the user's claim.
Are these lifetime deals or startup credits?
No. There is no pay-once license and no vendor application. The discount is whatever the product's Stripe coupon says: once, a number of months, or forever. The user becomes that product's customer.
How does the agent know a product is real?
The code is a Stripe promotion code, so the discount is the one Stripe will apply. If the founder opted in, the listing can also show monthly recurring revenue fetched from Stripe, usually as a band. A hidden listing has no revenue line.
Can the same agent also publish a coupon?
Yes, with the publish tools on its key. That flow is A go-to-market channel. Seeking and publishing are separate tools, so a seeker's key does not have to be able to publish.