Request count is not the same as provider cost

Listing stored connections is a small database read, while connecting or synchronizing an exchange performs signed provider calls, normalization and snapshot updates. A flat request quota hides that difference. Weighted credits make relative cost visible and allow an integration to choose cheaper metadata endpoints when it does not need fresh provider work.

Base weights combine with bounded multipliers

The catalogue publishes a base cost and maximum cost. Page-based reads multiply at 51–100 items, while history endpoints scale from short 24-hour and 7-day windows through an all-history maximum. Connection and synchronization operations stay fixed. GET /api/v1/usage/credits returns the live rules for budgeting and client-side warnings.

Observe cost and remaining balance on every response

Successful metered responses include X-Credit-Cost and X-Credits-Remaining. Capture them in server metrics and expose a useful threshold to operators before balance reaches zero. HTTP 402 with code insufficient_credits includes the attempted cost and remaining balance, allowing a product to pause nonessential refreshes and direct its billing owner to a credit pack.

Allocate credits to product jobs

Separate interactive user actions from scheduled refreshes and backfills. Reserve enough balance for connection and manual sync actions, cap background concurrency, and avoid refreshing users who have not returned. A simple daily budget per environment prevents a staging loop or broken scheduler from consuming the production integration's entire balance.

Connect credit spend to unit economics

For a consumer subscription, measure credits per active Free and Pro workspace, payment fees, provider failures and support load. For B2B use, measure spend per customer and feature. Credit packs are prepaid usage units rather than money stored in the account, so your pricing should include realistic refresh frequency and a margin for retries and incomplete provider data.