For Amazon agencies: the tools and agents your team runs clients on
Updated · By Ecomsellertool editorial team
Custom software for Amazon agencies is the internal tooling an agency runs client accounts on: client reporting portals, bid and budget rule engines, margin dashboards and AI agents that take the daily checks off account managers. Ecomsellertool builds it on Amazon's Selling Partner and Ads APIs, starting from Ecomsellertool Growth OS. Your agency stays the team your clients work with; we build the system behind it.
- Amazon Ads lists agencies with internal engineering resources among typical Ads API users; access needs an application and approval, and Amazon Ads charges no additional fee to use the API.
- A private SP-API app serves only your own organization, with up to 10 self-authorizations; a public seller app takes up to 25 seller authorizations unlisted, and no cap once listed in the Appstore.
- Amazon's SP-API documentation says sellers must reauthorize a public app every 365 days, or whenever the developer adds a role to it.
- Amazon's Solution Provider Portal FAQ says a service provider's access covers only its approved roles and is valid for 365 days, and every individual who accesses seller accounts must be verified.
- Our case studies include client profit analytics (Azzgency), an ads dashboard and rule engine (Vista Funnel), budget rules (TRAKTOR), a margin engine (Amazify) and Amazon and Walmart analytics (IVCSR).
- Ecomsellertool has built on Amazon's seller APIs since 2017, shipped 50+ tools and served 100+ teams.
Where it usually hurts
- Account managers rebuild the same client reports every week from Seller Central, the ads console and spreadsheets, and every client wants a different cut.
- Your bid, budget and negative-keyword playbook lives in spreadsheets and people's heads, so each account gets it a little differently and clients cannot see why a change was made.
- Clients judge you on profit, but your dashboards stop at ACoS because nobody has their landed cost and Amazon fees in one place.
- The rules your off-the-shelf tool cannot express end up back in spreadsheets, applied by hand for each client.
- Client access is split between service provider authorizations for your people and app authorizations for your tools, and Amazon asks sellers to renew both every 365 days.
What we build
- Client reporting portals on the Selling Partner and Ads APIs, with period comparisons, client logins and history your own system keeps.
- Rule engines for bids, budgets and negative keywords, attached to the campaigns you choose, with a log of every old and new value.
- Margin dashboards that combine each client's landed cost with Amazon fees and ad spend, per SKU and per campaign.
- AI agents for account-health checks, ad housekeeping and report drafts, acting within the rules you approve and sending the rest to an account manager.
- Walmart and other marketplaces in the same system, for clients that sell beyond Amazon.
What we have built for businesses like this
Many Amazon agencies run on a similar stack: Seller Central and the ads console for each client, a reporting tool or two, and spreadsheets that hold the playbook. It works until the client list grows. This page is for agency owners and operations leads who want tools of their own: the reporting portal, the rule engine, the margin view and the agents your account managers work from. If you would rather license a finished platform under your agency's name, our white-label page covers that route.
What do Amazon agencies build their own tools for?
Three jobs come up again and again. The first is client reporting. Account managers pull the same numbers from Seller Central, the ads console and spreadsheets every week, and each client wants a different cut. A reporting portal fed by the Selling Partner API and the Amazon Ads API builds those reports from one data set and keeps the history. That leaves the account manager free to write the part the client actually reads: what changed, and what to do next.
The second is the playbook. Your bid, budget and negative-keyword rules are what clients pay for, yet they often live in spreadsheets and people's heads, so each account manager applies them a little differently. A rule engine applies the same rules to every account you choose, within limits you set, and logs each change with the old value, the new value and the rule that made it. That log is also your answer when a client asks why a budget moved overnight.
The third is margin. Clients judge the agency on profit, while many dashboards stop at ACoS and TACoS. A margin dashboard adds each client's landed cost and Amazon fees, so a campaign can be judged on margin ACoS, where 100% is break-even. Agencies also build tools for client onboarding, account alerts and Walmart, when their clients sell there too. The build menu below shows where we have built each of these.
Which agency tools have we built?
Here is the build menu: tools we have built, most of them on Amazon's seller and ads APIs, each linked to its case study. Not every build on it was made for an agency, but the parts are the ones agencies ask for. Where a build runs on fixed rules, we say so. Rule-based automation is not an AI agent, and we do not call it one.
The agency build menu
| Tool | What it does for an agency team | Rules or model | Case study |
|---|---|---|---|
| Client onboarding and profit analytics | Admin and user panels, a fee breakdown and stock tracking per seller, and onboarding that fetched each existing client's past data, replacing the spreadsheets the team had used to manage clients | Software we built | Azzgency, a profit analytics app for Amazon sellers |
| Ads reporting dashboard | Sponsored Products, Sponsored Brands, Sponsored Display and Sponsored Brands video metrics in one dashboard, current period against previous, with active campaigns, keywords, audiences and product targets. A daily job fetches the past seven days of ad data again, so the figures stay aligned with Amazon's | Software we built | Vista Funnel, a team of digital marketers |
| Bid, budget and keyword rule engine | Raises or lowers bids and budgets, moves keywords between positive and negative targeting, applies each rule only to the campaigns and products you attach it to, and logs the target, old value, new value, rule and time | Rule-based automation we built | Vista Funnel |
| Budget rules with lookback windows | Checks criteria such as click-through rate, conversion rate and ROAS over today, yesterday, 7 or 14 days; runs hourly, daily or weekly; changes budgets by an amount or a percentage within minimum and maximum limits; logs every change | Rule-based automation we built | TRAKTOR |
| Margin engine and operator dashboard | Margin ACoS and organic cannibalization per SKU, campaign and period; revenue, ad spend and TACoS on one chart; ACoS, ROAS, CTR and CPC per campaign against the prior period | Software we built | Amazify, an Amazon growth team |
| Amazon and Walmart analytics with campaign rules | Sales, inventory and advertising from both marketplaces in one interface for multiple users, with low-stock alerts, order handling and Walmart item feeds | Software we built; the campaign rules are rule-based | IVCSR, which works with manufacturers on US retail and ecommerce accounts |
| Account alerts across seller accounts | Push and email alerts for hijackers, ASIN changes, parent-child splits, stranded inventory, listing faults, a suppressed Buy Box, negative seller feedback and performance metrics | Rule-based automation we built | AccountDr |
| Multi-brand social content workspace | One workspace for many brands, a knowledge pack per brand, post drafts for each network written from that pack, and scheduling | Software we built; the drafts use a language model | BrandGrid |
Three problems show up in agency builds, and they are worth planning for. Amazon's ad data is not instant: TRAKTOR's rules had to allow for Amazon processing times of 5 to 120 minutes, so we staggered the data requests and ran the most urgent budget updates first. Recent ad figures keep moving, which is why Vista Funnel's dashboard fetches the past seven days again every day. And API rate limits bite once dozens of client accounts sync at the same time, so Amazify's data layer runs on job queues and worker pools built to respect them.
Per-campaign ACOS, ROAS, CTR and CPC with period comparisons
Read the Amazify case study ↗Across all our work, we have built on Amazon's seller APIs since 2017, shipped 50+ tools, served 100+ teams and built integrations for 20+ marketplaces, as our brand facts page lists. The engineering side of that work, from app registration to rate limits, is on our Amazon SP-API development page.
Which agents save account managers the most time?
The ones that take over checks an account manager repeats for every client, every day. An agent does that work within the rules your agency sets for each client, and sends anything that commits a client's money or speaks for its brand back to a person. We build and deploy these agents on the accounts your clients authorize. They are designed to follow Amazon's Agent Policy, and each one separates the steps that follow fixed rules from the steps that use an AI model. The AI agents hub has a page for each one.
| Account manager task | Agent | Steps on fixed rules | Steps that use an AI model | What comes back to the account manager |
|---|---|---|---|---|
| Morning check of every client account | Account health agent | Per-client thresholds for suppressed listings, stranded inventory, a lost Featured Offer and listing enforcement actions | Reading Amazon's notices, and a plain-English summary on each alert | Appeals, disputes and plans of action, which a person edits and submits |
| Bid and negative-keyword housekeeping | Advertising agent | Break-even ACoS, days of cover, step limits, floor and ceiling bids, protected terms | A demand forecast per SKU, and a relevance check on each search term | Budget increases, budget moves and new keywords |
| Weekly client report | Report drafting inside your reporting portal | Every number, computed by fixed queries on the data your system keeps | A draft of the commentary, written from those numbers | The whole report, which the account manager edits and sends |
| Reimbursement and fee checks | Finance and recovery agent | Lost and damaged units matched against reimbursements, and claim windows | A draft claim written from the evidence it assembled | Every claim, which your team submits in Seller Central |
| Listing and catalog changes | Listing and catalog agent | Required attributes and field limits per marketplace, and drift checks against the client's product record | Drafts of titles, bullets and descriptions from that record, within each channel's limits | New listings and model-drafted copy, before they are first published |
| Reorders for clients whose inventory you run | Inventory and replenishment agent | Reorder point and safety stock | A demand forecast from noisy sales history | Purchase orders, before they reach a supplier |
Start with the task your account managers complain about most, and have every rule send its proposals for approval at first. Each proposal then sits next to what the account manager would have done, and you choose which rules may act on their own. The rules are set per client, so a conservative client and an aggressive one can share the same agent without sharing the same limits.
Custom build or white-label license?
It depends on whether your playbook is the product. A white-label license starts from a finished platform we have already built and runs it under your agency's name. A custom build starts from your rules and your reports. An off-the-shelf agency tool is a third option, and often the right one to begin with: SellerApp's agency page, for example, offers to handle your clients' accounts "in one centralized location" and says its agency pricing considers "the size and number of accounts" (checked September 25, 2026).
Three ways to get the tools your agency runs clients on
| Question | Off-the-shelf agency tool | White-label license | Custom build on Growth OS |
|---|---|---|---|
| Starting point | A product the vendor runs and updates | A finished platform we have already built, rebranded for your agency | Growth OS, plus modules written for your playbook |
| Whose rules it runs | The vendor's features and settings | The platform's existing features; custom modules are quoted separately | Your bid, budget, alert and reporting rules |
| Your brand on client screens | Depends on the vendor | Yes: the license covers operating it under your own brand | Yes, if you want client logins; set in the architecture doc |
| Code | Stays with the vendor | Complete source code in your repository; the underlying product IP stays with us, licensed to you | You keep your accounts, your data and the custom code we build; the Growth OS base is licensed to you |
| How it is priced | Set by the vendor, under its own plans | A one-time license fee plus a setup fee | A fixed price and go-live date per module in the architecture doc, plus the Growth OS base license |
| Who keeps it current | The vendor | Your team after 30 days of hypercare, trained to maintain it with AI; extra work is quoted | Agreed in the architecture doc before the build |
| The better choice when | A standard PPC and reporting playbook fits the tool, and you need it now | You want a finished platform under your name, and its features fit your clients | Your rules, reports and margin model are what clients pay you for |
The white-label route has limits worth knowing before you sign. Our published license terms grant one license to one company. Your agency may offer the running platform to its own clients under its brand, and charge them for access. It may not resell or sublicense the code, give a client the code, or let a client run its own copy. The underlying product IP stays with us, licensed to you, while modifications your team writes are yours. A second brand or legal entity needs its own license.
Stay with an off-the-shelf tool if your team runs a standard playbook and the reports it produces are good enough to send. Build when the tool keeps forcing workarounds: rules it cannot express, margin it cannot see, clients on Walmart it cannot reach, or reports your account managers rebuild in spreadsheets anyway. Our build vs buy comparison sets out the general cost and timeline trade-offs between SaaS, custom and white-label. This page covers what changes when the people using the software are your clients.
Who owns the code: you or us?
Three parties hold different parts of an agency's stack, and it pays to write down who holds what before the build starts. Your clients own their seller accounts, ad accounts, listings and history, and they authorize your agency's apps and people. Your agency holds its Amazon developer profile, its API apps, the data its system stores under each client contract, and the rules it runs. We hold the Growth OS base, which is licensed to your agency.
| What | Who holds it | How it stays that way |
|---|---|---|
| Clients' seller and ad accounts, listings and ad history | Your clients | They authorize your apps and your people, and can remove either at any time |
| SP-API and Ads API apps, and the developer profile behind them | Your agency | We recommend registering them under your agency's own developer profile, so every client authorization points at an app your agency controls |
| Data your system stores for each client | Your agency, under each client contract | Decide at scoping what is kept, for how long, and what happens when a client leaves, within your client contracts and Amazon's Data Protection Policy |
| Custom code we build | Your agency | Modules, integrations, rules and agents built for your playbook |
| Growth OS base | Licensed to your agency | Terms agreed before the build |
| Rules, limits and approval steps | Your team | Set per client, and changed when you decide |
This table is how we set up our builds, not legal advice; your client contracts and Amazon's policies decide the details. For the software itself, our position fits in one sentence: You keep your accounts, your data and the custom code we build; the Growth OS base is licensed to you. If you stop working with us, your accounts, data and custom code stay with you; the Growth OS base continues under its license terms.
The tools we build sit behind your agency. Your account managers stay the people your clients deal with, and a client-facing portal can carry your agency's name rather than ours. When a client leaves, it removes your access from its side: Amazon's Revoke Authorizations page says only the seller can revoke an app's OAuth authorization, which it does under Manage Your Apps (checked September 25, 2026). Your tools then stop reading that account. Our guide to giving an agency access safely covers the client's side of those steps.
What does an agency tech stack need before the first build?
Two registrations decide what your tools can reach. The first is your Selling Partner API app. Amazon's SP-API registration overview describes private apps as available only to your organization, and its authorization limits page caps them at 10 self-authorizations (both checked September 25, 2026). An app that reads client accounts is therefore a public app, authorized by each seller through OAuth: up to 25 sellers while unlisted, and no cap once listed in the Selling Partner Appstore. The overview says public developers must list their app there, and registration asks your tech team to answer security control questions, so plan both before the first client connects.
Choose the app's roles once. Amazon's Reauthorize Applications page says sellers must reauthorize a public app every 365 days, or any time you add a role to it, while its Seller Authorizations FAQ says Amazon deactivates only authorizations left unrenewed for more than 365 days with no API call in that time (both checked September 25, 2026). A new role is the change that reaches every client: add one in month six and each client has to reauthorize. List the data your tools will need at scoping and request the matching SP-API roles, such as Finance and Accounting, Inventory and Order Tracking or Product Listing, when you register the app.
The second registration is Amazon Ads API access. Amazon Ads lists agencies "that have internal engineering resources and that manage a significant volume of advertising campaigns for advertising clients" among typical API users. Its Ads API page says access requires an application and approval, and that there are no additional fees from Amazon Ads to use the API (checked September 25, 2026). The same page offers test accounts whose ads do not show on Amazon and incur no fees, which makes them the place to try a new bid or budget rule before it touches a client's campaigns.
People need their own route in, separate from the tools. Amazon's Solution Provider Portal FAQ says each individual who accesses seller accounts must be verified, that a service provider's access covers only the Seller Central roles it has been approved for, and that each authorization is valid for 365 days and renewable (checked September 25, 2026). Amazon is asking sellers to reauthorize providers on a rolling basis, with a deadline in each notice, and a provider that is not reauthorized loses access. Request approval for every role your team uses before clients are contacted, because roles outside your approval stop working once a client reauthorizes.
How do we start with an agency?
Ecomsellertool is a tech agency that builds the software Amazon agencies run their clients on. We start from Ecomsellertool Growth OS, connect it to the accounts your clients authorize through Amazon's Selling Partner and Ads APIs, and build the reporting portals, rule engines, margin dashboards and AI agents your playbook needs. Each module is scoped in an architecture doc with a fixed price and a go-live date.
- Call. Schedule a call from the card below. Bring the reports your account managers rebuild each week and the rules they apply by hand; that is usually where the first module comes from.
- Scope. We write the modules into an architecture doc, with a price and a go-live date for each, and plan the SP-API roles, the Appstore listing and the Ads API registration.
- Build. Growth OS goes live, connected to the client accounts that authorize it, and custom modules and agents follow on their dates.
- Roll out. Rules start by sending proposals for approval, and your team lets each one act on its own once its proposals match what an account manager would do.
If one client wants to see where its own account leaks first, the brand's team can connect it for the free 24-hour diagnostic: Login with Amazon, no password shared, and a report within 24 hours of connecting, on business days. We only read data; we never change listings, prices, stock or ads. Not an agency? Who we help has a page for Amazon-first brands, Shopify brands and 3PLs.
Frequently asked questions
Can our clients log in to the reporting portal themselves?
Yes, if you want them to. A custom portal can give each client a login that shows only its own accounts, with your agency's name on the screens. We agree the roles, what each client sees and the branding in the architecture doc before the build, so your account managers decide what goes out.
Will the AI agents change a client's account without our account manager?
Only within the rules you approve for that client. Routine steps, such as a bid change inside its floor and ceiling, run on their own and are logged with the old and new value. Budget changes, purchase orders, claims, appeals and anything that speaks for the client's brand come back to the account manager with the evidence and a proposed next step.
We have more than 25 seller clients. Does that change how the tool connects?
Yes. Amazon caps an unlisted public SP-API seller app at 25 OAuth authorizations and a private app at 10 self-authorizations, and an app at its limit cannot add more. A public app listed in the Selling Partner Appstore has no cap, and Amazon's registration overview says public developers must list their app there anyway. We plan the registration and the listing before the build, so you do not hit the limit halfway through a rollout.
What happens if our tools need more client data later?
Each new kind of data usually means a new SP-API role, and Amazon says sellers must reauthorize a public app whenever its developer adds a role, as well as every 365 days. Adding a role later therefore means asking every client to reauthorize. We list the data your tools will need at scoping and request those roles when the app is registered.
Can we sell a tool you build for us to other agencies?
Talk to us before you plan it. You keep your accounts, your data and the custom code we build; the Growth OS base is licensed to you. Selling a product built on that base to other agencies is a different use from running your own clients on it, so it needs its own agreement, settled before the build. For comparison, our published white-label terms grant one license to one company and allow no resale or sublicensing.
What happens when a client leaves our agency?
The client disables your app in Manage Your Apps and removes your service provider access in Manage Services, and your tools stop reading that account. Its seller account, listings and ad history were always its own. Agree at scoping what your system does with that client's stored data and reports when a contract ends, within your client contract and Amazon's Data Protection Policy.
Do we have to start from Growth OS, or can you build one tool on its own?
Our engagements start from Ecomsellertool Growth OS, the base system for listings, replenishment, orders, warehousing, advertising and reporting, because an agency tool needs the same data plumbing underneath. Your custom modules are built on top of it. If you want a finished platform under your own name instead, the white-label license is the other route.
Can our clients' Walmart accounts sit in the same system?
Yes. For IVCSR we built Amazon and Walmart sales and advertising analytics in one interface, with Walmart item feeds and order handling. What your tools can change in Walmart advertising depends on the API access each account has, so we check that per client at scoping.
