the upwork api won't let you send proposals. here's the one that will.

Last week a GigRadar user named Ned Thomas sent me a message that stopped me mid-coffee. He had pointed Claude Code at our API and built a pipeline that generates a brand new, one-off landing page for every Upwork client he bids on.

Not a template with fields swapped. A unique Next.js site, written from scratch for that specific job, deployed to its own URL. From the scanner firing to the bid landing in the client's inbox, the whole thing takes 12 seconds.

Ned Thomas Built a 12-second proposal pipeline using Claude Code and GigRadar's API

"It basically has allowed me to generate entirely custom proposals, links with graphs and also timeline breakdowns + testimonials, all within 12 seconds of receiving data from GigRadar Scanners."Ned Thomas, GigRadar API user

You can see a live example of the output he shared at proposal.nedthomas.co.uk/a5zf4kxxy2cz. Here's roughly what the client sees when they click the link inside Ned's Upwork proposal.

Here's the thing most developers don't realize. The official Upwork API cannot send proposals.

Not with any scope, not with any workaround, not with any approval tier. Upwork's public GraphQL API lets you read jobs, fetch profiles, and pull messaging metadata, but the mutation for submitting a proposal simply does not exist in the schema.

So when Ned says the pipeline "auto-submits the bid," he isn't using Upwork's API. He's using ours.

what the official upwork api actually does (and doesn't do)

Upwork opened their public GraphQL endpoint at https://api.upwork.com/graphql in 2023. On paper it looks powerful.

You can query job searches, pull client histories, fetch your own profile stats, and read messages from contracts you're already working on. What you cannot do, and what most growth hackers discover two weeks into a project, is submit a proposal.

I went through the full Upwork GraphQL schema last month to confirm this hadn't quietly changed. It hadn't.

This is deliberate on Upwork's part, and they've been public about why. Bid spam is the single largest trust issue on the platform, and an open submission API would make it worse.

how gigradar submits proposals to upwork (the business manager model)

GigRadar is not a partner of Upwork. There is no commercial agreement, no official integration, no private API key from Upwork's engineering team. I want to be exact about this because the wrong version of the story gets told a lot.

What GigRadar actually operates is a real Upwork Business Manager account. GigRadar owns that account as a company, and it sits inside GigRadar's own organization on Upwork the same way any agency's BM account sits inside theirs.

When an Upwork agency signs up for GigRadar, they grant our Business Manager access to their own Upwork agency account. That is the same mechanism any Upwork agency uses to give a virtual assistant, a bidder, or a hired business manager the ability to see job feeds and submit proposals on behalf of the agency.

Every proposal that gets submitted through the GigRadar API flows through our Business Manager account under our own team's supervision. There is no scraping. There is no browser extension running on your machine. There is no session cookie from your logged-in Upwork account being passed through a cloud.

It is the same action your own hired bidder would take, just executed by GigRadar's infrastructure instead of a human clicking through the UI. That is the entire trick, and it is the only legal way to submit proposals programmatically on Upwork right now.

what the gigradar api exposes

The endpoints live at https://api.gigradar.io/public-api/v1/ and they authenticate with a simple X-API-Key header. Four of them matter for Ned's use case.

GET /gigs returns the job posts your scanners have matched in real time. The response includes the full Upwork payload: title, description, budget, client history, hire rate, Connects cost.

POST /opportunities/{id}/application submits a cover letter and bid amount to Upwork on your behalf via GigRadar's Business Manager. This is the endpoint that does what the official Upwork API cannot.

It accepts the opportunity ID from the scanner payload, your rendered cover letter body, your proposed rate, and optional answers to screening questions. The response confirms whether the submission went through and returns the Upwork-side proposal ID.

POST /webhooks lets you register a callback URL. GigRadar will POST to it every time a new job matches a scanner, so you don't need to poll.

Ned's entire pipeline lives inside a single webhook handler. Request in, Claude Code generates and deploys a unique landing page, application call out, done.

GET /opportunities/{id} returns the full detail on any job, including the screening questions the client attached to the post. You'll need this to render custom answers in your pipeline.

ned's pipeline, reconstructed (with claude code)

I asked Ned for permission to reverse-engineer his setup so other agencies could build something similar. He was generous with the details.

The important thing to understand up front: Ned is not calling the Claude API from a script. He is running Claude Code as the execution engine, and Claude Code is the thing that actually writes, builds, and deploys a brand new Next.js project for every proposal.

That design choice is the whole reason his proposals feel different from every other "AI-generated" bid on Upwork. His pipeline does not fill a template. It writes a new site.

the actual code you'll write

I'll walk through each piece in the order it runs. The shape is identical in any language, but the snippets below are the minimum viable versions in JavaScript and Python.

1. the webhook receiver

Your endpoint receives a JSON body with the opportunity ID, job title, description, and scanner metadata. Validate the signature header, hand the payload to your generation step, return a 200 fast so GigRadar doesn't retry.

2. the claude code session

This is where most developers try to over-engineer. You don't need a multi-agent orchestration, you don't need RAG, you don't need a custom prompt framework. You need one Claude Code session with a clear system instruction: "read this job description, scaffold a Next.js project that presents a custom proposal for it, then deploy to Vercel and return the URL." Ned's entire system prompt is about 600 tokens.

3. the deploy (handled by claude code)

There is no separate deploy step. Claude Code runs the Vercel CLI directly from inside its session, captures the returned URL, and prints it on the last line of its output. Your handler just reads stdout.

4. the submission call

One HTTP call to GigRadar. The response tells you whether the proposal went through, how many Connects were consumed, and the Upwork proposal ID so you can track it later.

the discipline question you should ask before building this

I want to be direct about one thing most tutorials skip. Running an automated pipeline against Upwork does not remove your obligation to bid well.

Ned submitting 40 genuinely custom proposals a day with a 22 percent reply rate looks fundamentally different to Upwork's ranking models than someone pushing 200 generic bids a day with a 2 percent reply rate. The API is a tool, not a shortcut.

If you build Ned's pipeline and you point it at every job in a category with a lazy prompt, you will still tank your Job Success Score and get deprioritized in Upwork's feed. The pipeline works because the bids are actually good.

what you need to start

Three things get you from zero to a working prototype.

1. A GigRadar account with the API plan enabled. The plan sits on top of the Scanner tier, so you need at least one active scanner matching your target jobs.
2. An API key. You'll find it in your GigRadar dashboard under Settings, API Access.
3. A host for your webhook receiver and page generator. Vercel, Cloudflare Workers, and Render all work fine.

The minimum scanner setup is one Scanner pointed at jobs in your niche. Filter for payment-verified clients, minimum budget, and client hire rate above 60 percent.

Ned runs four scanners in parallel targeting slightly different keyword clusters. This matters because the scanner filters determine the quality of the payload your pipeline operates on.

Bad scanner, bad proposals. Claude Code cannot rescue a pipeline pointed at garbage jobs.

Once the scanner is live, you register your webhook URL at POST /webhooks and point it at your endpoint. Within about 10 minutes you'll start receiving payloads as matching jobs appear in the Upwork feed.

From there you're in your own code, and the only external dependency you have is the final /opportunities/{id}/application call.

why this changes the agency math

The reason I'm writing this article instead of letting Ned keep his edge is that the economics have quietly shifted for agencies on Upwork. Most people haven't caught up.

Two years ago, the winning strategy was speed. First 5 minutes, generic-but-polished proposal, high volume, low close rate but high enough reply count to make the math work.

Upwork's Uma ranking model has mostly killed that approach. Speed without relevance gets you buried.

The new winning strategy is relevance at speed. That's only possible if you automate the parts of the relevance work that a human can't do fast enough.

Building a custom landing page in 12 seconds is not something a VA can do. It requires an agent that can write code (Claude Code) and an API that can submit the resulting bid without a human touching the Upwork UI (GigRadar).

The agencies I've seen win this quarter are the ones that figured out the second half of that sentence before their competitors did. The GigRadar API is the piece that makes the submission leg work through a real Business Manager account instead of a scraper.

frequently asked questions