Your web app stores each article — App Service only runs it.
The App Service API manages web apps, app settings, deployment slots, deployments and hostnames; it has no post, page or article resource, so nothing inside App Service can hold an article. Your web app can. Whether it runs on a built-in stack — .NET, Node.js, Python, PHP or Java — or from a custom container, one receiver endpoint checks DraftSEO’s signature and saves the post to your database, and your app renders it like any other page.
| App Service content API | None — apps, settings, slots, hostnames — the App Service API has no post, page or article resource |
|---|---|
| Receiver | One endpoint in your web app — built-in stacks or a custom container, recipe per framework |
| Signature check | HMAC over timestamp and body — your app recomputes it from ${timestamp}.${rawBody} and drops deliveries older than 5 minutes |
| Free (F1) and Shared plans | Cold starts, no Always On — unloaded after 20 idle minutes, so a delivery can outlast the 10-second test |
| App-enforced HTTPS | Trust X-Forwarded-Proto — App Service ends TLS in front of your app, and a redirect fails the delivery |
Who does what
Pick the stack your web app runs, add its receiver, and put the signing secret in an app setting. When the signed test clears, articles need nothing from you — your controllers, views and database schema remain your own.
Click Apply — App Service restarts the app with the new value by itself.
Setup
On App Service the receiver is ordinary app code; what trips a delivery up is the plan tier, the domain and HTTPS.
Connect a site → Azure App Service, then choose ASP.NET Core, Next.js, Node.js / Express, Astro, SvelteKit, Nuxt (Vue), Expo, PHP (plain), Laravel, Django, FastAPI, Java / Spring or Kotlin (Ktor) — or Ruby on Rails, Go, Rust / Axum or Elixir / Phoenix from the container group. That stack’s receiver recipe appears next to your signing secret.
~1 minute
Under Settings → Environment variables → App settings, add DRAFTSEO_WEBHOOK_SECRET and click Apply — or set it from the Azure CLI with az webapp config appsettings set. A custom container also needs the app setting WEBSITES_PORT=8080.
~2 minutes
Verify the HMAC over ${timestamp}.${rawBody} and write the post to a database — only /home survives a restart, and SQLite’s locking fails on that share. FastAPI needs a uvicorn Startup Command; Laravel needs NGINX pointed at its public folder.
~10 minutes
Copy the Default domain from the app’s Overview page, register its https:// address, and your endpoint receives a signed test delivery — and a deliberately invalid one, which your receiver must reject. On Basic (B1) or higher, turn on Always On first.
~2 minutes
Articles post to your web app as they are generated, with images, slug and SEO fields attached.
Ongoing · zero clicks
FAQ
No — App Service keeps no content of its own for anything to publish into. Its API manages web apps, app settings, deployment slots, deployments and hostnames, with no post, page or article resource. DraftSEO publishes into the web app App Service runs, and that app is what renders your blog.
Everything on the built-in stacks: ASP.NET Core on .NET; Next.js, Node.js / Express, Astro, SvelteKit, Nuxt and Expo on Node.js; PHP and Laravel on PHP; Django and FastAPI on Python; Java / Spring and Kotlin (Ktor) on Java SE. Ruby on Rails, Go, Rust / Axum and Elixir / Phoenix have no built-in stack, so they run as a custom container with WEBSITES_PORT=8080 set so App Service routes to the recipe’s port.
Yes, with a managed Azure Functions API. A Static Web Apps site runs no server code of its own, so the connect wizard gives you a ready-to-paste function that acts as the receiver and answers at /api/webhook.
Free (F1) and Shared plans unload your app after 20 minutes without requests and cannot turn on Always On, so a delivery can wait on a cold start for longer than the 10-second test allows. On Basic (B1) or higher, switch on Always On under Settings → Configuration → General settings.
Not reliably. On the built-in stacks only /home survives a restart, and SQLite’s file locking fails on that network share. Keep posts in a database instead — Azure Database for PostgreSQL works.
No card required. Signed test delivery in under a minute.