Splitwise
Read and write Splitwise expenses, groups, friends and comments — including the full per-user share model.
About
Splitwise ships in the w6w first-party pack. It declares 26 actions, 3 health checks, and the host runs its code in a sandbox that never sees the credential.
- App id
io.w6w.splitwise- Version
- 0.1.2
- Author
- w6w
- Licence
- MIT
- Categories
- Finance & Accounting · Productivity
Overview
Splitwise settles who owes what from inside a workflow — expenses carry the full per-person share model (who paid, who owes) that a plain equal split can’t express, alongside the groups, friends and comments that give each one its context.
An expense can be split equally or by explicit per-person shares, updated, deleted and undeleted, and read back with its running balance; groups and friends are created, listed and managed, including invites and member removal. Comments thread onto an expense for context, and currencies, categories and notifications round out the picture for building a coherent expense-tracking workflow.
It fits roommate, travel and shared-household automations that create an expense from another system — a receipt scan, a booking confirmation — keep a group’s membership current, or surface Splitwise’s own notification feed as a change log, against a single personal account’s full-access API key, since Splitwise offers no narrower credential.
Build with Splitwise
Three routes to the same 26 actions. The Workflow tab is generated from Splitwise'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.
Add User To Group
add-user-to-group Add a user to a group, by user id or by email plus both names. An email nobody owns creates an invited placeholder user.
Create Expense (By Shares)
create-expense-by-shares Create an expense with an explicit per-user split: who paid what, and who owes what. Both columns must total the cost.
Create Expense (Split Equally)
create-expense-equal Create an expense split equally across a group's members. The connected account is the payer — Splitwise offers no way to say otherwise in this form.
Create Friend
create-friend Add a friend by email. If nobody owns that address Splitwise creates an invited placeholder user, for which a first name is required.
Delete Comment
delete-comment Delete a comment. Splitwise returns the deleted comment rather than a flag.
Delete Expense
delete-expense Delete an expense. Soft: it stays readable with a `deleted_at` and can be restored with Undelete Expense.
Delete Friend
delete-friend Break off a friendship, by the friend's user id. Splitwise publishes no endpoint to restore one.
Delete Group
delete-group Delete a group. Splitwise destroys all associated records — the group's expenses go with it. Reversible with Undelete Group.
List Categories
list-categories Splitwise's expense categories, as the raw parent tree plus a flattened list of the subcategories — only a subcategory id is valid on an expense.
List Comments
list-comments The comment thread on an expense. Splitwise mixes its own System audit entries into it, so the human-written ones are also returned separately.
List Expenses
list-expenses The current user's expenses, filterable by group, friend and date, with offset paging. Deleted expenses are included, carrying a `deleted_at`.
List Friends
list-friends Every friend of the current user, with per-currency balances overall and per group. The usual way to resolve an email address to a Splitwise user id.
List Groups
list-groups Every group the current user belongs to, including the synthetic group 0 that holds expenses belonging to no group.
List Notifications
list-notifications Recent activity on the account, newest first — the only change feed Splitwise offers, since it publishes no webhooks.
Remove User From Group
remove-user-from-group Remove a user from a group. Splitwise refuses while that user has a non-zero balance in it.
Update Expense
update-expense Change fields on an existing expense. Supplying shares REPLACES the whole split — send every participant, not just the ones changing.
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 Splitwise's real ids.
{
"manifestVersion": "2",
"name": "splitwise-example",
"steps": [
{
"id": "add-user-to-group",
"uses": {
"app": "io.w6w.splitwise",
"action": "add-user-to-group",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"groupId": "<groupId>"
}
}
]
}Here are some of the things you can do
-
Add User To Group
performadd-user-to-group -
Create Comment
performcreate-comment -
Create Expense (By Shares)
performcreate-expense-by-shares -
Create Expense (Split Equally)
performcreate-expense-equal -
Create Friend
performcreate-friend
+21 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 Splitwise, 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 Splitwise. 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: "create-expense-equal",
payload: {
group_id: "<value>",
description: "<value>",
cost: "<value>",
// currency_code: "<value>",
// category_id: "<value>",
// date: "<value>",
// details: "<value>",
// repeat_interval: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value);npm install -g @w6w/cliw6w run conn_YOUR_CONNECTION_ID --action create-expense-equal --payload '{"group_id":"<value>","description":"<value>","cost":"<value>"}'Give an AI agent Splitwise — without giving it Splitwise'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.splitwise#add-user-to-group",
"input": {
"groupId": "<groupId>"
}
}
}
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 Splitwise connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
What the agent gets
Credentials it can't read
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.
A tool surface scoped to the caller
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.
A durable workflow in one call
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.
Health-aware discovery
Splitwise'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. Splitwise itself is MIT, and the runtime that executes it is source-available (FSL).
Health checks
Splitwise declares its own checks, so its health is a property of the app rather than something the host guesses at.
Splitwise platform status
Component status from status.splitwise.com (Instatus). The verdict follows the `API` component alone — the surface every action here calls; `Website` and `Splitwise Pay` are reported for attribution but never move it.
API reachability
Unsigned GET of /api/v3.0/get_current_user. A JSON 401 is the pass — it proves the v3.0 router is mounted and the auth filter ran. An HTML 404 means the version was withdrawn.