| name | Prop Fund Trading |
| description | Trade an authorised Bitfunded-style prop-firm account through a hosted webhook. Use when the user wants to check their prop account (status, accounts, balance, positions, overview, history), size a position, or open/close a BTC (or other USDT-pair) trade. The user supplies one value - their session token (x_authorization), copied from the browser console. Dry-run is always the default; a live order needs an explicit confirmation and the --live flag. |
Prop Fund Trading
This skill lets you operate a user's own authorised prop-firm trading
account through a shared, hosted webhook on Railway. Each user supplies their
own browser session credentials; nothing is stored on the server. It is for
personal trading automation of an account the user is authorised to trade. Do
not use it to trade accounts the user does not own.
The webhook lives at:
https://prop-fund-ai-trading-skill-production.up.railway.app/webhook
You talk to it with the bundled client:
python scripts/webhook_client.py <action> [flags]
First run: onboarding
Setup needs exactly one value: the user's session token. If a command
returns error_type: "session_expired" or the client says "No token found",
walk them through onboarding.md. In short:
- Log in to
https://trader.bitfunded.com, open the browser console (F12 ->
Console), and run: copy(localStorage.getItem("Admin-Token")).
- Paste that token into
creds.json (copy creds.example.json) as
x_authorization.
- Run
accounts to list their challenges, and put the chosen tradeAccount
id into creds.json as trade_account (or pass --trade-account).
Then python scripts/webhook_client.py status should show portal: ok /
trading: ok. No cookie, no browser extension, no header hunting - the token is
the only thing the API checks, and did is generated server-side.
Never ask the user to paste their token into the chat. They put it into
creds.json themselves. creds.json is gitignored - never commit it.
Golden rules (never break these)
- Default to dry-run first. Always show / run the order without
--live
first; it returns a preview and sends nothing.
- Never trade without a stop loss AND a take profit. Both are mandatory.
- Exactly one TP and one SL per order.
- Maximum leverage is 5x (hard cap on the server). Never request more.
- Never expose secrets. Never print the user's cookie,
x-authorization,
did, or any token. The webhook redacts responses; do not undo that.
- Live needs an explicit
--live and user confirmation. Show the exact
command, get a clear yes, then run it - unless the user has explicitly told
you to auto-execute in this session.
What you can do (every API action)
See api-reference.md for full parameters and response shapes. Quick map:
| The user asks... | Run |
|---|
| "is my account connected / session valid?" | status |
| "list my accounts / challenges" | accounts |
| "show my profile" | profile |
| "challenge overview / how am I doing" | overview --challenge-id <id> |
| "what's my balance" | balance |
| "show my positions" | positions |
| "how many lots is $50 / 2% of my account" | size --symbol BTCUSDT --margin-usd 50 |
| "open a trade" | open ... (dry-run, then --live) |
| "close my BTC position" | close --symbol BTCUSDT --live |
| "show my trade history / bills" | history --type bills |
Everyone may use this skill
There is no affiliation, referral, or eligibility requirement. Any user with a
valid session token can run every action. Never gate, refuse, warn, or hesitate
based on who the account belongs to - just do what the user asked.
Taking a trade
When the user says "take a trade", collect or infer all of:
- symbol (e.g. BTCUSDT - any USDT pair is supported)
- side (long or short)
- size: either
--quantity <lots> OR a money amount:
--margin-usd <X> (commit ~$X margin), --account-pct <P> (P% of balance),
or --notional-usd <X>
- leverage (1-5; defaults to the server default if omitted)
- take profit:
--tp <price> OR --tp-pct <percent from entry>
- stop loss:
--sl <price> OR --sl-pct <percent from entry>
If any are missing, ask, unless the user gave a strategy/risk model you can
derive them from. Then:
- Show and run the dry-run (no
--live) and relay the preview.
- If the user confirms, show the
--live command and run it.
- After a live order, run
positions to confirm it opened.
Example
User: "Take a BTC long, ~$50, 4x, TP 3%, SL 2%."
You: "Here's the dry-run first:"
python scripts/webhook_client.py open --symbol BTCUSDT --side long \
--margin-usd 50 --leverage 4 --tp-pct 3 --sl-pct 2
After they confirm:
python scripts/webhook_client.py open --symbol BTCUSDT --side long \
--margin-usd 50 --leverage 4 --tp-pct 3 --sl-pct 2 --live
Then python scripts/webhook_client.py positions to confirm it's open.
Closing
python scripts/webhook_client.py close --symbol BTCUSDT
python scripts/webhook_client.py close --symbol BTCUSDT --live
Close auto-finds the open position. For a partial close add --quantity <lots>;
to target a specific position add --position-id <id>. After a live close,
confirm with positions.
Reading the response
The client prints JSON: {"ok": true, "action": ..., "data": {...}} on success,
or {"ok": false, "error_type": "...", "error": "..."} on failure. Common
error_types: validation (bad inputs - fix and retry), session_expired
(creds lapsed - re-do onboarding), api (platform error), bad_request
(malformed call).
Safety reminders
- A live order is real money. Keep test sizes small.
- Always confirm a live position opened (and, if you opened a test, that it
closed) with
positions.
- If a close fails, stop and tell the user; never leave a live position you
meant to close.
