Why bring-your-own API keys matter in seller software
Bring-your-own API keys mean your Amazon SP-API and Keepa quota is yours alone rather than pooled with other customers, at the cost of setup work first.
Last reviewed 5 min readSupplyForge LLC
Bring-your-own API keys are worth insisting on: with per-tenant credentials your Amazon SP-API throughput and Keepa token spend are yours, not shared with every other customer of the software.
Pooled credentials are the opposite arrangement — the vendor registers one application, every customer's lookups run through it, and the vendor absorbs the cost and the quota. Pooling is faster to start and worse under load, and the difference shows up the day you import a supplier catalog.
Pooled credentials and per-tenant credentials, compared
Pooled and per-tenant credentials differ on six things that matter to a working seller, and setup speed is the only one where pooling wins.
| Aspect | Pooled vendor credentials | Per-tenant credentials |
|---|---|---|
| Rate limit | Shared across the vendor's customer base | Governed by your own credentials |
| Keepa tokens | Metered and bundled by the vendor | Burned in your own Keepa account |
| Noisy neighbor | A stranger's 50,000-row import competes with yours | No other customer can touch your quota |
| Setup before first use | Minutes: sign in | Credentials first, matches second |
| Leaving the vendor | The credential relationship stays with the vendor | Your keys and authorizations stay yours |
| Usage visibility | Whatever the vendor's dashboard shows | Calls appear in your own Amazon and Keepa records |
The choice is architectural rather than a setting: a vendor that pooled credentials to make onboarding fast cannot un-pool them for one demanding customer. Ask which model a tool uses during the trial, not after the first import.
Forge Command uses the per-tenant model throughout. Every tenant supplies its own API keys, stored encrypted at rest with Fernet, and the cloud worker that enriches catalog rows uses each tenant's own credentials.
Every credential a Forge Command tenant has to supply
Bring-your-own means a real shopping list, and only the first row is required before the catalog engine does anything useful. The rest turn on modules you may not need yet.
| Credential | What it turns on | Who pays for the usage |
|---|---|---|
| Amazon SP-API | ASIN matching, pricing, fees, restriction checks | Your own Amazon quota |
| Keepa | Buy-box winner counts, monthly sales, price history | Your paid Keepa tokens, opt-in |
| Helium 10 | Revenue and velocity estimates, uploaded as CSV | Your Helium 10 subscription |
| Gmail | Outreach sequences, reply detection, open tracking | Your Google account |
| Quo (OpenPhone) | Call transcripts, summaries, next steps | Your Quo subscription |
| Anthropic Claude | Business AI chat over your tenant data | Your Claude API spend |
| QuickBooks and Plaid | Chart of accounts, transactions, bank feeds | Your accounting and bank accounts |
| Apollo.io and Lusha | Contact sourcing and enrichment | Your own credits |
Only the Amazon SP-API row is load-bearing for catalog matching. Keepa, Helium 10 and Quo each add a data layer the engine runs without, and Apollo is keyed per user rather than per tenant. Set the Amazon credentials first and confirm a small scan returns ASINs before adding anything else — how to match a supplier catalog to Amazon ASINs covers that scan.
What pooling does to a 30,000-row catalog import
A pooled credential turns your import speed into a function of what strangers are doing. Forge Command calls Amazon SP-API in batches of 20 identifiers per request across three endpoint families — catalog, pricing and fees — so a 30,000-row supplier list is 1,500 requests per family, roughly 4,500 for one pass. Trim the last two families by the 10–15% of rows that never match an ASIN, normal on a real wholesale catalog, and the pass still lands above 4,000 requests.
Per-tenant keys fix quota contention and not queue contention. Forge Command's enrichment worker is shared infrastructure draining every tenant's queue, so another tenant's large import can still put your rows behind theirs in worker time. What per-tenant credentials guarantee is narrower: you are never throttled because someone else spent your allowance.
Who owns the Amazon and Keepa relationship
Per-tenant credentials make you the counterparty to Amazon and Keepa, not the vendor. Your SP-API access is an authorization your selling account granted and can revoke on its own. Your Keepa lookups spend tokens from your own subscription — opt-in in Forge Command because they cost real money — and the burn is visible in your Keepa account.
Under a pooled model the vendor holds the relationship and your usage is one line inside their bill. That matters at two moments: when something is throttled and you have no standing to ask why, and when you switch tools, since per-tenant keys move with you. Amazon SP-API explained for sellers who are not developers covers what the authorization grants.
The setup work that has to happen before anything matches
Bring-your-own keys mean the software is inert until the credential work is finished, and this is the real cost of the model. For Forge Command that means SP-API credentials for your selling account, a Keepa key for buy-box and sales history, Helium 10 CSV exports, Gmail OAuth for each sending mailbox, and QuickBooks and Plaid before any finance module fills.
Forge Command has no shared fallback pool. Environment-variable credentials apply only to the original seed tenant, so a new tenant with no keys has a catalog engine that matches nothing at all — not a degraded version, nothing. Budget an afternoon, then keep integration settings admin-only, covered in how to give a VA system access safely.
When pooled credentials are the better trade
Pooled credentials are the better choice in four situations. If you are evaluating a tool and want an answer this hour, pooling wins. If you do not yet have SP-API access on your selling account, pooling is the only thing that works. If your workflow is single-item lookups rather than whole-catalog passes, the quota argument never bites. And pooling moves key rotation to someone else.
Bring-your-own is also not unique to Forge Command. Clay supports bring-your-own API keys across most of its integrations, so a Clay user can spend credits already paid for elsewhere (Clay's published integration model, checked 2026-08-03). Across the general CRM and prospecting tools checked the same day, none integrates Amazon SP-API.
Frequently asked questions
Does Forge Command work without my own Amazon keys
Partly. Catalog matching, pricing, fee estimates and restriction checks need SP-API credentials and return nothing without them. Contact, organization and note records do not depend on Amazon, so the CRM side is usable first.
Do I need a Keepa key as well
No. Keepa is opt-in in Forge Command and costs your own paid tokens per lookup, so it is a deliberate spend. Keepa adds 30-day distinct buy-box winner counts, monthly sales and price history. See Keepa versus Helium 10 sales data.
Whose quota does the enrichment worker consume
Yours. Forge Command's cloud worker drains every tenant's pending queue using that tenant's own stored credentials, in batches of 20 identifiers per request. No other tenant can spend your allowance.
How are the stored keys protected
Credentials are encrypted at rest with Fernet and scoped to the owning tenant, and tenant data is separated by PostgreSQL row-level security enforced in the database. Forge Command holds no SOC 2 or ISO certification. See multi-tenant data isolation for business data.