Upgrade.Chat

Upgrade.Chat is the payments and membership platform for Discord and Telegram communities. Agents list and inspect orders, products, and users, and audit webhook configurations and their delivery log to keep community access in sync with what was paid.

10 actions OAuth available

Upgrade.Chat website Platform Documentation Capability data verified 2026-08-25

The weekly entitlement sweep runs against the community's paid roles

List Orders reads every purchase and renewal in the period, resolved per member

List Products turns each order's product reference into the roles that purchase actually grants

List Webhook Events is read across the same window to confirm no purchase notification was missed

Granted roles in the community are compared against what the ledger says was paid for

The proposed revocation list is posted with each member's last order date, amount, and product

The community manager confirms the list before any role is removed

What This Integration Enables

Upgrade.Chat sells memberships inside Discord and Telegram communities, and this connector is deliberately one thing: the record of who paid for what. There are no write operations. Nothing here grants a role, cancels a membership, or changes a product. Ten operations read orders, products, buyers, webhook configuration, and the delivery log, and one of them verifies that a delivery is genuine.

That read-only shape is the whole design consideration for an agent, because every consequence of what this connector says lands somewhere else. The role is granted in Discord, the welcome goes out through your own channel, the entitlement is written to your own records. So the question is never whether the agent may act on Upgrade.Chat. It is whether the picture the agent has assembled is complete and genuine enough to act on somewhere else. FlowRunner agents build that picture continuously, and the act that follows from a gap in it reaches a person, which is what human-in-the-loop protects against here.

Without FlowRunner

Access drifts away from payment Roles granted at purchase stay in place after a subscription lapses, because nothing sweeps them

Unsigned notifications acted on A delivery arriving at your endpoint is trusted because it arrived

Outage gaps invisible Purchases that happened while an endpoint was down are simply missing, and nothing says so

With FlowRunner

Access reconciled to the ledger The paid record and the granted roles are compared on a schedule, with every difference named

Notifications verified before they are acted on Each delivery is checked against the platform's own record before a role is granted

Gaps replayed from the platform's copy The delivery log is read across the window your endpoint missed, which is what recovery looks like here

Use Case Scenarios

A purchase notification that is verified before it grants anything

A delivery arrives at your endpoint saying a member upgraded. Upgrade.Chat does not sign its deliveries, so a POST is an unverified claim and anyone who learns the URL can imitate it. The agent calls Validate Webhook Event with the delivery's id first, which is the platform's own substitute for a signature, and only then reads the order in full to see what was bought and which roles it grants. List Products turns the product reference into a name and interval a person recognizes. The role is granted in Discord, the welcome goes out, and the entitlement is written to your own records with the order id attached so the grant can be traced back to a payment.
Recovery after an endpoint was down

Your handler was unavailable for a few hours. There is no resend route on this platform, which means reading the delivery log is the replay. The agent lists webhook events across the outage window, fetches the platform's own copy of each body rather than trusting anything that may have arrived half-formed, validates each id, and processes the gap in order. Members who paid during the outage get their access without anyone opening a support ticket, and the community manager sees a short note in Slack saying how many were recovered rather than discovering the gap through complaints.
Answering what a member is entitled to

A moderator asks why someone has a particular role. Filtering orders by that member's community identifier returns their whole purchase history, with the order type separating recurring memberships from one-off shop purchases. The agent resolves each product, assembles a plain answer, and posts it back in the thread: what was bought, when, at what price, and which roles each purchase grants. It is the same read the sweep uses, applied to one person, and it replaces a manual look through a billing dashboard.

Human-in-Loop Highlight

This connector cannot revoke anything, and that is exactly why the revocation gate belongs here. A lapse sweep reads the paid ledger and proposes a list of members to strip roles from, but the act happens in Discord, and stripping the role of somebody who is actually paying locks a customer out of the community they bought. Two properties of this API make that error easy to reach. The buyer list is buyers only, so a member who joined some other way never appears in it at all, and it takes no search parameter. And there is no resend route, so if a purchase notification was missed and never replayed from the delivery log, the ledger the agent is reading is quietly incomplete rather than visibly wrong.

So the sweep does not revoke. It posts the case to the community manager: "7 members hold Supporter with no order in 46 days. 5 last paid on a monthly product that has not renewed. 2 have no order on record at all, which usually means a manual grant rather than a lapse. Webhook delivery log shows no gap in this window. Revoke the 5, and leave the 2 for review?" The two with no record are the ones a rule would get wrong, and the delivery-log line is what lets a person trust the other five. The list is assembled in seconds. The removals wait for a yes.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

10 actions

Orders

List Orders Lists every purchase and renewal the community has taken. Filtering by a member's community identifier returns their whole purchase history, and the order type separates recurring memberships from one-off shop purchases.
Get Order Reads one order in full: what was bought, by whom, for how much, and the roles or entitlements it granted. It is addressed by the order's own identifier rather than a community one.

Products

List Products Lists the products the community sells, recurring and one-off, with prices, intervals, and the roles each grants. This is the catalog that turns an order's product reference into something a person recognizes.
Get Product Reads one product with its price, billing interval, and the roles it grants.

Users

List Users Lists the people who have bought something, with their community identifiers. It is the buyer list rather than the server's member list, so somebody who joined and never paid does not appear, and it takes no search parameter.

Webhooks

List Webhooks Lists the endpoints configured on the account with their URLs and the events each receives. It is read only, since webhooks are created and edited in the platform's own developer settings.
Get Webhook Reads one webhook configuration: its URL, its events, and whether it is active.
List Webhook Events Lists the deliveries the platform has attempted, newest first. With no resend route available, reading this log is the replay for anything your endpoint missed.
Get Webhook Event Reads one delivery including the body that was sent, which is how a flow works from the platform's own copy rather than from whatever reached the endpoint.
Validate Webhook Event Asks whether an event id is one the platform genuinely sent. Deliveries are not signed, so this call is what makes an incoming notification trustworthy, and it belongs before a role is granted or anything is shipped.

Frequently Asked Questions

What can FlowRunner do with Upgrade.Chat?

FlowRunner agents can run List Orders, Get Order, and List Products in Upgrade.Chat, plus 7 more actions.

Does connecting Upgrade.Chat to FlowRunner require OAuth?

Yes. Upgrade.Chat connects to FlowRunner with OAuth 2.0, so agents authenticate without handling raw credentials.

Can Upgrade.Chat trigger a FlowRunner workflow automatically?

Upgrade.Chat doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Upgrade.Chat

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us