resolveInventoryService

Resolve a chain’s inventory-service configuration. getInventoryTvl runs it first, so a chain without an inventory deployment fails with a typed error instead of issuing a request to a service that is not there.


import { resolveInventoryService } from "@symmio/trading-core";
 
const { url } = resolveInventoryService(config, chainId);

Availability is chain-level: the chain either carries an inventory block or it does not — there is no solver capability to declare, so the second argument is a bare chain id, exactly like the { chainId } target resolveListingService takes. Today only Arbitrum carries an inventory service.

The service is optional per chain, so a miss throws rather than falling back to another chain’s deployment. Falling back would report a different system’s TVL, and a wrong number is worse than an error: it looks like data.

Parameters

configConfigrequired

The SDK config.

chainIdnumberoptional

Chain to resolve. Defaults to the config’s default chain when omitted.

Both functions take the same two positional arguments — (config, chainId?), not an options object.

Returns

SymmioInventoryConfig

urlstring

Inventory service host root — no path segment and no trailing slash, e.g. https://inventory85.enigma.bz.

The url is a host root on purpose. The generated client’s own paths already begin with /api/v1, so appending /api would request /api/api/v1/markets/tvl-aggregate and 404. Point it at staging (https://inventory-staging.enigma.bz) with a createConfig override — there is no separate environment axis.

Throws

Both are a SymmError with kind: "config", raised before any network call:

INVENTORY_NOT_CONFIGURED — the resolved chain has no inventory block.
UNSUPPORTED_CHAIN — the chainId is not a chain the config knows about at all. This one comes from config.getChainConfig, before the inventory block is ever looked at.

The first message names the chain and the fix, so it reads as a configuration task rather than a failure:


Pools: chain <chainId> has no inventory service configured. Set `inventory.url` for this chain in `createConfig({ symmioConfig })`.

supportsInventoryService

The non-throwing twin. Same two arguments, returns a boolean.


import { supportsInventoryService } from "@symmio/trading-core";
 
if (supportsInventoryService(config, chainId)) showTvlCard();

It swallows every failure resolveInventoryService can raise — a chain with no inventory block and a chain id the config does not know — and returns false. That second case is what makes it safe to call with a chain id straight off a wallet, before you know whether the SDK supports that chain at all.

Which to use

Situation	Reach for
Inside an action or server handler that cannot proceed without the service	`resolveInventoryService`
Deciding whether to render a TVL card, tab, or route	`supportsInventoryService`
An `enabled` flag on a query or hook	`supportsInventoryService`
You need the `url` itself	`resolveInventoryService`

The rule of thumb: throw where absence is a bug, and return false where absence is just a chain that does not have this product. Writing resolveInventoryService inside a try to produce a boolean is supportsInventoryService spelled out longhand.


const enabled = supportsInventoryService(config, chainId);
 
const { data } = useQuery({
  ...getInventoryTvlQueryOptions(config, { chainId }),
  enabled,
});

getInventoryTvl — the read that resolves the service for you.
Inventory — the slice overview, including the host-root rule and the 18-decimal contract.
resolveListingService — the two-half equivalent for the Pools listing backend.
Errors — the SymmError hierarchy these codes belong to.