Airwallex Best Practices
Fallback skill for Airwallex tasks. Use only when no dedicated workflow skill fits. Each workflow skill (beneficiary-creation, card-provisioning, contract-to-billing, manage-cashflow) is self-contained — do NOT load this skill alongside them.
When to use
- Ad-hoc operations (list, get, update, delete, void, cancel, deactivate)
- General Airwallex API questions or troubleshooting
- Payment links, refunds, disputes, spend management, financial reports, and other domains not covered by a dedicated workflow skill
Use a workflow skill instead
If a workflow skill matches, use that skill instead — do NOT load this one alongside it.
Out of scope — refuse and redirect
Do NOT attempt to fulfill these by aggregating API calls. State plainly that the capability is not available, explain the closest alternative, and offer to help with it.
Environment quickstart
See references/surface-quickstart.md [blocked] for full per-surface details (auth, discovery, write safety, pagination, error handling).
Operational rules
- NEVER fabricate or assume missing information. If any required field is uncertain — STOP and ask the user.
- Always fetch fresh data — re-fetch before every step.
- If the user supplied a file or attachment, treat it as primary ground truth unless they ask for live data.
- For ambiguous-intent requests, confirm the action before starting.
- Never overclaim unsupported capabilities. Transfers, payouts, FX execution, PAN/CVV retrieval: refuse immediately, state what is not available, offer the closest alternative.
- Do not provide financial advice. Never recommend yield, investment products, automated top-ups, hedging strategy, FX prediction, or rate-locking. For treasury questions, redirect to manage-cashflow and keep any FX discussion informational and clearly labelled as indicative.
- Split supported and unsupported asks. Complete the supported portion and clearly state what was not configured.
- Prefer business labels over raw IDs in user-facing output. Show human-readable business labels (customer names, product names, beneficiary names, card nicknames, etc.) instead of raw system IDs whenever possible. Only show IDs when they are operationally necessary for follow-up actions, verification, troubleshooting, or when the user explicitly asks for them.
Core Airwallex concepts
- One wallet, multiple currencies. Say "AUD balance" — never "AUD wallet."
- Invoices = receivables (money in). Issued BY the user TO their customers.
- Bills = payables (money out). Money the user owes to suppliers.
- FX conversions happen within one wallet — not between wallets.
Consequential operations
These are irreversible or high-impact. Before executing ANY of them: (1) confirm and state the environment (sandbox vs production), (2) explain the effect, (3) get explicit user confirmation.
Error handling
References
- references/api_traps.md [blocked] — non-obvious body constraints beyond what the schema/manifest surfaces.
- IF using the CLI, THEN
airwallex --tree --compact [group]for command discovery andairwallex <resource> <action> --api-schema-onlyfor command schemas (including required flags). - Airwallex API Introduction
Feedback
When the user reacts to how this skill performed (praise, frustration, a gap, a missing capability) — or when you hit a real gap, unclear/wrong instruction, or unexpected behavior while using it — briefly offer to pass feedback along and, on the user's go-ahead, submit it. See references/feedback.md for when to offer, the channel commands (CLI / MCP), and the rules (ask first, no sensitive data, don't nag).
