Your deployed Emergent app receives every article — one prompt sets it up.
An Emergent app is a React front end over a FastAPI backend and a MongoDB database, and only requests under /api ever reach the backend. DraftSEO’s prompt works with that split: the agent adds a signed POST /api/draftseo-webhook route, keeps posts in MongoDB and images in GridFS, and builds /blog as React routes — so articles arrive on their own, while the pages themselves render in the browser.
| What Emergent builds | FastAPI route + MongoDB posts + React /blog routes — added to the app you already have |
|---|---|
| Deploying | Standard plan or above — previews are private and expire after 30 minutes |
| Security | HMAC over timestamp + raw body — compared with hmac.compare_digest; anything older than 300 seconds is refused |
| Images | Stored in MongoDB GridFS — served from /api/images on your app, not from DraftSEO’s CDN |
| SEO | Client-rendered React pages — search engines must run JavaScript to read each article |
| Changing the secret | Update the deployed environment — a redeploy never overwrites an existing .env value |
Who does what
Paste the prompt into your Emergent chat, deploy the app, and have Emergent write the signing secret into the backend .env before redeploying. When the test delivery goes green, articles need nothing further from you.
Rotating the secret? Change it in the deployed environment too.
Setup
Open the Emergent tile and copy the build prompt DraftSEO prepares for it.
~30 seconds
The agent adds the signed /api/draftseo-webhook route to your FastAPI backend, a MongoDB posts collection with GridFS for images, and React routes for /blog.
~a few minutes
Deploy on the Standard plan or above — a preview can’t receive articles. Add the deployed URL ending in /api/draftseo-webhook in DraftSEO, then ask Emergent to put the signing secret in the backend .env and redeploy.
~a few minutes
Click the send icon and look for a green delivery. Your receiver must also answer DraftSEO’s deliberately invalid signature with a 401 before the endpoint counts as connected.
~1 minute
New articles now flow into your deployed Emergent app on schedule, with no redeploy per post.
Ongoing · zero clicks
FAQ
Your app never needs one. The prompt has Emergent’s agent add a receiver to your own FastAPI backend at /api/draftseo-webhook, save each article to a MongoDB posts collection, and answer DraftSEO’s posts.list requests for internal linking. DraftSEO then sends every finished article there as signed JSON, and the backend turns away anything whose signature doesn’t match.
Only by running JavaScript. On Emergent, every path outside /api returns the React app’s JavaScript shell rather than finished HTML, so /blog cannot be rendered on the server. The prompt builds /blog and /blog/:slug as React routes that load published posts from /api and set the page title and meta description from each post — the article text is not in the HTML a crawler first receives.
No. A preview is private and expires after 30 minutes, so there is no lasting public address to deliver to. Deploy the app — deploying needs Emergent’s Standard plan or above — and register the deployed URL ending in /api/draftseo-webhook, not the home page, which answers with a web page instead of receiving the delivery.
The deployed app is likely still checking against the old value, because a redeploy never overwrites a value that already exists in the .env file. Update DRAFTSEO_WEBHOOK_SECRET in the deployed app’s environment as well. If only the URL was wrong, fix it with the pencil (Edit) icon instead of deleting the webhook — deleting issues a brand-new secret.
In your own database. Emergent has no built-in file storage, so the prompt tells the backend to download each image when an article arrives, keep it in MongoDB GridFS and serve it from /api/images/{id}, rewriting every img src to that address. The live article therefore doesn’t depend on DraftSEO’s CDN staying online.
No card required. Emergent runs the app; DraftSEO keeps its blog stocked.