Backend API (Core SDK granular skill)

Granular skill for BackendApiService — sodax.backendApi. HTTP client used by every feature for reads + swap-tx submission. Feature tag for errors varies by call site (e.g. 'swap' for submitSwapTx, 'moneyMarket' for MM reads); errors always carry error.context.api: 'backend'.

Step 1 — Clarify with user before coding

1. New code or v1 → v2 port? Note: v2's load-bearing change is Result-wrapping every method (v1 threw on failure).
2. Which category?
   • Swap-related reads / writes: submitSwapTx, getSubmitSwapTxStatus, getOrderbook, getIntentByHash, getIntentByTxHash, getUserIntents.
   • Money-market position reads: getMoneyMarketPosition, getAllMoneyMarketAssets, getMoneyMarketAsset, getMoneyMarketAssetBorrowers, getMoneyMarketAssetSuppliers, getAllMoneyMarketBorrowers.
   • Config-API methods (implements IConfigApi): getAllConfig, getChains, getSwapTokens, getSwapTokensByChainId, getMoneyMarketTokens, getMoneyMarketReserveAssets, getMoneyMarketTokensByChainId, getRelayChainIdMap.
3. Custom IConfigApi for sandbox / fixtures? Every method must return Promise<Result<T>> in v2.

Integration workflow

1. ../integration/knowledge/ai-rules.md.
2. ../integration/knowledge/features/backend-api.md — BackendApiService API + submitSwapTx call shape + custom-backend pattern.
3. For the submitSwapTx + createIntent flow → also load ../swap/SKILL.md or read ../integration/knowledge/features/swap.md § "Backend submit-tx flow".
4. Errors carry error.context.api === 'backend' → ../integration/knowledge/recipes/result-and-errors.md and ../integration/knowledge/reference/error-codes.md.