Amazon Ads API developer — bid automation engine for an existing dayparting tool

About us and the tool We are an ad agency. We run an in-house Amazon Ads dayparting tool for our own accounts — it is not a product we sell. The tool collects hour-by-hour campaign performance and shows it as a 7×24 heatmap (day of week × hour of day). An operator sets bid modifiers per hour — "bid 30% less on Sunday at 3am". About 21,000 lines, NestJS backend and Next.js frontend, PostgreSQL. We manage roughly 40 advertiser accounts across the US, the UK and Europe, through our own Amazon developer application. What already works This is not a greenfield build. Everything up to the last step exists: Amazon account connection. OAuth login, credentials stored encrypted, access renewed automatically. Our advertiser accounts are synced from Amazon. Campaign and keyword sync. Campaigns and keywords are pulled in and stored with their current bids. Hourly performance data. Impressions, clicks, spend and sales arrive from Amazon Marketing Stream through a queue, are de-duplicated, and are rolled up into hourly totals per campaign. CSV backfill. Hourly reports exported from Amazon's console can be uploaded to fill in history the live feed does not cover. Validated first, imported on confirmation. The heatmap. The 7×24 CPC grid, with date ranges, range comparison, excluded periods, and a display showing which days have incomplete data. The settings screen. Bid modifiers per hour and target ACOS, at both account and campaign level, saved and reloaded. Three screens in total. The backend has tests covering the aggregation and parsing. What we need built One thing is missing: nothing in the tool ever sends a bid to Amazon. An operator can open the heatmap, click an hour, set "−30%", and it saves. No bid changes as a result — not then, and not on any schedule. Every call the tool makes to Amazon reads; none of them write. That gap is the job. We need an hourly process that, for each account: determines the current day of week and hour in that account's own local time; resolves the modifier that applies (campaign level overriding account level) and the target ACOS; calculates the new bid from the stored baseline, within Amazon's bid limits for that marketplace; writes the resulting bids to Amazon, handling rate limits, retries and partial failures; records what it changed. Two conditions that shape the work Local time. "3am" has to mean 3am where that account sells. The system works in UTC only today. Regions. The Amazon Advertising API is split by region. The tool is configured with a single API host for all accounts. Establishing what that means for our accounts is part of the first milestone. Four requirements, not extras This spends real money unattended, so these are part of "done": Audit log — every bid change recorded: which keyword, when, from, to, and under which rule. Dry-run mode — reports exactly what it would change and changes nothing. Baseline restore — one operation returns every bid to its original value. Crash safety — a failed or repeated run must never leave bids stranded at a modified value. Who we are looking for Required Strong TypeScript, comfortable in NestJS, Prisma and PostgreSQL. Comfortable working against a third-party REST API with rate limits, paging and awkward error behaviour. Careful with automated processes that spend money — you can explain how you make unattended jobs safe. Strongly preferred Hands-on Amazon Advertising API experience, particularly writing to it rather than only reading. Scheduled work run across regions and timezones, with daylight saving, in production. Experience automating live ad spend. We know the Amazon Ads API combination is not common. If you have the required list and have worked with a comparable API, tell us — we would rather hear from you than not. Allow for the learning curve in your estimate and say so; we would rather have that stated openly than discovered later. The codebase is consistent, uses exact decimal types for money, timezone-aware timestamps and versioned migrations, and has tests on the parts where correctness is hard. Architecture and data-model documentation exists and will be provided.