Boomerang lead export request desk and credit ledger

I want an internal list-request desk for my team's Boomerang lead exports. The app opens on a queue board. Anyone on the sales team submits a request by pasting an Apollo, Sales Navigator, or Crunchbase search URL, the number of rows they want, and a one-line reason for the request. The new card sits in a Pending approval column until a sales ops admin reviews it. The app stores the requester, the reason, the requested row count, and the source URL as its own app-side fields, because Boomerang does not track any of them.

When an admin approves a card, fire the matching Boomerang submit operation based on the source URL: Submit Apollo Export for Apollo URLs, Submit Sales Navigator Export for Sales Navigator URLs, and Submit Crunchbase Export for Crunchbase URLs. Save the returned Boomerang request id on the app-side record so the app can always join its own fields back to the live job, then move the card off the board and into the jobs table. An admin can also decline a request with a short note, which closes the card without spending any credits.

The jobs table is the main view. It reads Boomerang List Requests and shows every job with its status, export type, requester, row count, credits reserved, and credits used. Give it tabs for In queue, Completed, and Issue. Use those three status values exactly as Boomerang writes them, capitalized and with a space, because they are the only values the service ever returns. Page the table with limit and offset and read total off the response to know when to stop, rather than fanning out a lot of calls, because the API allows only 60 requests per minute and 600 per hour per key.

Each row has a Download button. When it is clicked, call Get Request Status for that request id at that moment to mint a fresh signed CSV link, then hand that link to the user. Never store a link and reuse it later. Boomerang output links are time limited and carry an expiry timestamp, so the app has to re-poll every single time somebody wants the file.

Each row also has a Notify button that sends the requester a Slack message containing a freshly minted download link, the export type, the row count, and the credits used. Open a direct message conversation with the requester first to get the DM channel id, then send the message to that channel.

A second view is a credit ledger that rolls spend up by requester and by month, using credits used on completed jobs, and shows credits reserved next to credits used so the team can see where the estimate and the actual charge diverge. Whenever a job first appears as Completed, append a ledger row to a Google Sheet with the date, requester, export type, row count, credits reserved, credits used, and the reason, so finance has a running record outside the app. Append each job exactly once and do not duplicate rows on later refreshes.

Bake in that exports cap at 300000 rows, and reject anything above that at submit time with a clear message rather than letting the job fail downstream. Keep the reason field required, since it is what makes the ledger readable months later.