It looks like you’re from {country}
Communication
A company running its community on Discord is usually one of a few kinds of business: a game studio or gaming-adjacent brand, a creator with a paid membership, or an open-source or software project where Discord is where the users already talk to each other. None of those are the audience most integration copy is written for, and pretending Discord is a Slack substitute for a regular office misses what it is actually good at.
What is worth connecting is narrower than a CRM feed: who has paid and should get access, which role somebody should hold, and which handful of events the community itself should hear about. Everything else — sales pipelines, invoicing, HR — belongs on a different page in this bank, not bolted onto a Discord server.
Discord is a chat platform organised around servers, channels and roles, built originally for gamers and now the default home for a much wider set of online communities. A webhook is the simple route in: a URL posting a message into one channel, no server-side code, similar in spirit to a Slack incoming webhook — enough for one-way alerts such as a new sale or a stream going live.
A bot is the other route, and the one that can do more than talk: it can read who is in the server, assign or remove a role, respond to a slash command, or check whether a Discord account is linked to a paying customer before letting them into a members-only channel. Running one means hosting it reliably and keeping its token secret, more infrastructure than a webhook but what any membership logic actually needs.
These come from running membership by hand on a platform that was never built to check who has paid.
A member cancels their subscription on the website. Nobody on the Discord side is told, so the paid role stays, the paid channels stay visible, and the only way this gets caught is a manual audit somebody eventually dreads doing.
What you see instead
A cancellation on the site removes the role within minutes, automatically, the same way an active subscription grants it.
Somebody subscribes, has to be told to join the Discord server and which channel is theirs, then waits — sometimes days — for a moderator to notice and assign the role by hand. The membership bought on impulse has cooled off by the time it actually starts.
What you see instead
Payment triggers the invite link and the role together, so joining the server and getting access are the same action, not two steps with a wait between them.
A well-meaning setup announces every sale, new member and small update to the whole server. Within weeks most members have muted it entirely, which means the one announcement that mattered — a launch, an outage, a real event — reaches nobody either.
What you see instead
Announcements worth a ping are rare and named as such; routine activity goes into a low-traffic channel people can check without being interrupted.
For a membership business the honest cost is not staff hours, it is churned revenue nobody traces back to the cause. A cancelled member who keeps paid access for even two weeks before somebody notices is two weeks of a product given away free — multiply that by the cancellations in a month and it is a real number, even at a modest price.
The other side of the same coin is lost sign-ups: a new member waiting on manual role assignment has time for second thoughts, and some never follow up to ask. Neither shows up on an invoice the way retyped orders do, which is why they go unmeasured until someone runs the numbers.
This is usually a website project first: the subscription logic lives on the shop or membership site, and the Discord side is the bot that reads it — so a Discord connection on its own is rarely the whole job.
A connection needs two ends. Plenty of agencies will build you the API call and hand you a JSON payload; that is the easy half. The harder half is what the data lands in — a website, a webshop, a portal your customers log into, an internal tool that replaces a spreadsheet. JKC builds both ends, which is why the connections we build tend to keep working: nothing about the receiving side is a black box to us.
The connection itself: authentication, field mapping, rate limits, retries and a queue that survives the other system being down for an hour. Built against the documented API where there is one, and against whatever the vendor really offers where there is not.
WordPress sites that read from your systems instead of repeating them by hand: a careers page fed by your HR system, a team page that follows your payroll, prices and availability that are the real ones.
WooCommerce shops where the order is the last time anyone types it: it becomes an invoice in your accounting package, a label at your carrier, a stock mutation in your warehouse, and a line in your CRM, on its own.
When the process does not fit any standard product: a customer portal, a quoting tool, a planning board, a dashboard that reads three systems at once. Built on your data, with your systems as the source instead of a copy of them.
Membership and roles need a bot with real permissions; plain announcements only need a webhook. We say which each row needs, since it changes the setup and the moderation rights the server owner has to grant.
Role granted or removed on subscription status (out of the tool)
A paid role assigned the moment a subscription goes active, and removed the moment it lapses or cancels — the flow that actually protects a members-only channel.
Invite link issued on payment (out of the tool)
A unique or time-limited invite sent right after checkout, so joining the server and paying happen in the same minute rather than an email read later.
New sales or top supporters into an announcement channel (into the tool)
A specific milestone — a sale over a set amount, a new top donor — posted to one channel, not every transaction to every channel.
Slash commands that look up account or order status (both ways)
A member typing a command to check their order status or membership expiry, answered by the bot from the website's data without a support ticket.
Rows one and two are the pair almost everyone who asks for this actually needs; the announcement and slash-command rows come later, once the membership logic itself is solid.
The same four steps every time, whichever tool it is. Nothing here is a workshop you pay for: step one exists because scoping a connection wrong is the single most expensive thing that can happen to it.
Not "which fields exist" but "which fields does somebody currently move by hand, how often, and what breaks when they get it wrong". Most projects turn out to need two or three flows, not a full two-way sync of everything. That conversation is what keeps the quote where it is.
A maintained connector from the vendor, a platform like Make or Zapier, or a custom integration against the API. Cheapest first, not custom first: if a supported plugin does exactly what you need, that is the answer and we will tell you so. Custom is for the cases where the off-the-shelf option would need so much configuring that it becomes the fragile option.
Every connection ships with retries, a queue and an idempotency key, so an order that arrives while the other side is down is delivered later rather than lost, and a retry does not create a second invoice. On a test environment first where the vendor offers one, so the first thing your real administration sees is a working connection.
Which alerts you will get, what each one means, what to do about it, and who to call. Plus the credentials in your own name, in your own vault — not in ours. A connection nobody but us can maintain is a connection you do not own.
This is the part most quotes leave out. A connection that stops working without telling anyone is worse than manual work, because with manual work at least somebody notices when it does not get done. Every connection JKC builds is monitored, and the monitoring is not an upsell — it is in the service fee.
A message that does not get through raises an alert the same hour, with the record it was about. Not a dashboard you have to remember to look at.
Anything that failed sits in a queue and can be sent again once the cause is fixed, in order. Nobody goes back through yesterday to find the four orders that did not land.
APIs get versioned, deprecated and rate-limited. When a vendor announces a change that affects your connection, adjusting to it is part of the service fee, not a new project.
A webhook-only announcement sits at the bottom of the range and is often a small addition to a shop project already underway. A bot that manages roles against a real subscription status is a step up from that, closer to a mid-range connection, because it has to run continuously and hold its own credentials safely.
A connection starts from €1,700 plus a monthly service fee, which covers the monitoring, the queue and keeping up with the vendor's API changes. Work outside a fixed scope is €95 per hour.
What moves the number is not the tool — it is how well the system on the other end is known. If JKC built your website, your webshop or your web application, we already know its data model, its edge cases and where its stock numbers really come from, and a connection into it is mostly configuration and testing. If it is a system we have never opened, we start with a short technical check of both sides and quote after that, so you are not paying hourly for us to work out the basics.
Two more things that move it, in our experience more than anything else: whether the tool has a real API or only a CSV export, and whether the sync has to go both ways. One-way is roughly half the work of two-way, because two-way means deciding, per field, which system wins when they disagree — and that decision is the expensive part, not the code.
Both, and the honest answer is that it depends on where your community already is. If your customers are on Discord anyway — common for games, software tools with a technical audience, and creators with a paid membership — meeting them there beats asking them to also check a forum or a Facebook group nobody opens.
It is a poor fit for a regular B2B business with no community angle, and we will say so rather than build a Discord server nobody will use.
The website tells it, not the other way around: when a subscription activates, cancels or lapses, the shop or membership plugin fires an event our bot listens for, matched to the member's Discord account through an account link they made once — typically by clicking a 'connect Discord' button while logged in.
That link is the part worth getting right: without it, all the bot can see is a Discord username with no guaranteed connection to a real customer.
That is a real limitation and worth being honest about: a role, once granted, does not check minute to minute whether the person using it is still the paying customer. Removing the role on cancellation closes the main gap; anything beyond that is a moderation and community-management question more than a technical one.
Most clients accept this the same way they accept password sharing on any subscription service — a cost of doing business, not a problem a connection can fully solve.
To a limited degree — Discord's own API exposes who joined, who has which role, and message counts per channel, but not much about individual message content, and rightly so. A member's role status can sync into a marketing tool like Mailchimp so a segment stays accurate, but treating a Discord server as a data-collection surface tends to work against the trust that makes people stay on it.
We would rather build the two or three flows that genuinely help than a broad sync that makes the community feel surveilled.
