Operator workspace · private context stays out of the document
Your context in. A personalized brief out.
Task 4 follows your six-part structure: headline, current situation, likely problem, solution, alternative options, and a specific CTA. Task 5 is the separate email that introduces the asset.
Authored reference · not an API-generated result
Linear: a personalized support brief
Public workflow facts, a clearly labelled hypothesis, a practical solution, an honest options comparison, and a walkthrough CTA.
Authored example · fictional prospect
LifeCore: a wellness coverage plan
A prospect-facing plan for People & Benefits leadership: check useful access, compare options, and design an opt-in pilot. Same six-part format, different buyer problem and content.
What to pass
For a useful result, put these five things in one prompt:
- Product: what the seller does and the problem it helps solve.
- Prospect: the company name and domain, if known.
- Buyer: the selected person’s role; name is optional.
- Observed facts: the signal, relevant data, source text, and source links. Say what is unknown or hypothetical.
- Your reasoning: why those facts matter to this buyer. Keep this distinct from verified evidence.
Optional: Task 1 filters, score and scoring logic, a preferred asset type, approved logo URL/colors, or relevant profile information. Scores and qualification notes guide the writer but stay off the prospect’s document.
Include sourced examples from similar companies if you want them used. No examples supplied means no invented case studies. To include a gift offer, add the separate approvedGiftOffer field only after you have approved the gift and its terms. It does not purchase a gift.
A domain or LinkedIn URL is not enough for research. The current writer does not open those pages. Pass the useful findings from Clay, not just the links. Without evidence, the result must be a proposed plan—not an audit claiming work was performed.
Website and content generation are separate
Vercel hosts the pages, receives Clay requests, and stores finished documents. A separate generator writes the content. No AI Gateway is used or required.
The authored examples work independently of the generator. New-company generation still needs a verified connection to the separate service; the two-minute target has not yet been measured successfully.
One prompt in. A document URL out.
This prepares the request only; it does not call the generator. The example is deliberately fictional.
POST /api/assets · Content-Type: application/json
Authenticate from Clay with Authorization: Bearer [your private API key]. Never put that key in this prompt.
Preview the exact JSON body
{
"prompt": "Product: AccessProof helps digital teams test websites and applications for accessibility problems and coordinate remediation.\nProspect: Northstar Commerce, a fictional online retailer. No real domain supplied.\nBuyer: Head of Digital Product.\nObserved facts: None about this fictional prospect. A checkout redesign is a hypothetical practice scenario, not a verified event. No accessibility audit has been performed.\nMy reasoning: A redesign is a useful moment to plan accessibility testing. It is not proof of existing defects.\nKnown capabilities: testing customer-facing websites and applications for accessibility problems and coordinating remediation. No other capabilities are verified.\nSimilar-company evidence: None supplied; do not invent a case study.\nCreate the six-part brief: headline, current situation, likely problem, solution, best alternative options (include AccessProof as one option), and a CTA offering a walkthrough of the proposed checkout testing plan. Label this fictional practice scenario. No invented findings, sources, metrics, or brand identity. No gift approved. Keep qualification and the separate outbound email private."
}The simplest body has only one field: prompt. You do not need to design the output JSON or write the six sections yourself. A successful API response includes assetUrl for Task 4 and a separate, private task5Hook for Task 5.