- Published on
Newsletter API route: Pliny + Buttondown in MDX
- Authors
- Name
- Jacob Walker
- @JacobWalker03
Newsletter API route: Pliny + Buttondown in MDX
The homepage embed posts emails straight to Buttondown. For in-MDX subscribe flows that go through my Next app, I use Pliny’s BlogNewsletterForm, backed by /api/newsletter and Buttondown’s API.
Stack
app/api/newsletter/route.ts– Exports GET/POST from Pliny’sNewsletterAPI, withprovider: 'buttondown'(driven bysiteMetadata.newsletter.provider).BlogNewsletterForm– Registered inMDXComponentsso any post can include that component in MDX.- Env –
BUTTONDOWN_API_KEY(see.env.example). Without it, this path isn’t useful; the embed path on the home page still works without the key.
Embed vs API-backed form
| ButtondownEmbedForm | BlogNewsletterForm + /api/newsletter | |
|---|---|---|
| Submit target | Buttondown embed URL (browser) | POST /api/newsletter → Buttondown |
| API key | Not required | Required (BUTTONDOWN_API_KEY) |
| UX | Full page navigation on submit (typical HTML form) | Pliny’s client-side handling |
I use the embed for the main site CTA and anywhere I want zero server coupling. I use BlogNewsletterForm when I want the Pliny newsletter component behavior inside a post or page.
Config touchpoints
data/siteMetadata.js–newsletter.provider: 'buttondown'for the API route;buttondownEmbedUsernamefor the embed (independent concerns)..env.example– Documents that the key is only for the API/MDX form path.
That’s the plumbing: one provider in config, two subscribe surfaces depending on whether the browser talks to Buttondown directly or through my route.