Read and manage Raisely campaigns, fundraiser profiles, donations, supporters (users), recurring subscriptions and tags — the peer-to-peer fundraising platform.
Raisely ships in the w6w first-party pack. It declares 22 actions, 3 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.raiselyRaisely is a fundraising platform for nonprofits: campaigns (donation pages, peer-to-peer and event fundraising), the fundraiser profiles that raise money inside them, the one-off donations and recurring subscriptions they collect, and the users (supporters/donors) behind all of it. This app covers that core surface over the Raisely API v3 — listing and reading campaigns, profiles, donations, users, subscriptions and tags; updating campaigns, profiles, donations, users and subscriptions; creating users and offline donations; and assigning or removing tags on records.
Three things about Raisely’s API are worth knowing before scripting against it. First, most reads work with NO credential at all — Raisely serves public data to anonymous callers — so this app always asks for the private (full) record, which is what a key is for. Second, every request and response is wrapped in a data envelope, and lists carry a pagination object (total, pages, offset, limit) driven by limit/offset. Third, Raisely returns each user’s own accessToken inside user records; this app strips that field from every response so a supporter’s login token never lands in a workflow run.
Three routes to the same 22 actions. The Workflow tab is generated from Raisely's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
campaign-list List the campaigns on the connected Raisely organisation, newest first unless sorted.
campaign-update Update a campaign's name, goal, currency, mode, domain or custom fields.
donation-create Record a donation against a campaign or profile — typically an offline or custom gift. Card payments need a gateway token this action does not take.
donation-list List donations, optionally filtered by campaign, profile, user, subscription, status, mode or type.
donation-update Update a donation's donor details, message, anonymity, fundraiser thank-you or custom fields. Amounts and payment details cannot be changed here.
profile-list List fundraiser profiles in a campaign (individuals, teams and organisations).
profile-update Update a fundraiser profile's name, goal, description, photo or custom fields.
subscription-list List recurring donation subscriptions, optionally filtered by campaign, profile, user, status, mode or source.
subscription-update Update a recurring donation's amount, schedule, donor details or custom fields.
tag-record-add Assign a tag to one or more records (users, profiles, ... of the tag's record type).
user-create Create a user (supporter or donor). With Merge on, an existing user with the same email is updated instead of a new one being created.
user-get Retrieve one user (supporter or donor) by uuid. The user's login accessToken is stripped from the result.
user-list List users (supporters and donors), optionally filtered by email, name, country, postcode or phone.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying Raisely's real ids.
{
"manifestVersion": "2",
"name": "raisely-example",
"steps": [
{
"id": "campaign-get",
"uses": {
"app": "io.w6w.raisely",
"action": "campaign-get",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"campaign": "<campaign>"
}
}
]
}campaign-get campaign-list campaign-update donation-create donation-get +17 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for Raisely, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to Raisely. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "campaign-get",
payload: {
campaign: "<value>",
// includeTags: "<value>",
// pruneConfig: "<value>",
// private: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action campaign-get --payload '{"campaign":"<value>"}' Give an AI agent Raisely — without giving it Raisely's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.raisely#campaign-get",
"input": {
"campaign": "<campaign>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's Raisely connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Raisely's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. Raisely itself is MIT, and the runtime that executes it is source-available (FSL).
Raisely declares its own checks, so its health is a property of the app rather than something the host guesses at.
The API component on Raisely's Statuspage (www.raiselystatus.com) — not the Websites, Payment Processing or Admin Panel components, which degrade independently.
Unauthenticated GET api.raisely.com/v3/campaigns. Raisely's JSON `forbidden` / `unauthorized` refusal passes — it proves the API and its auth layer are answering.