Content revalidation
For statically generated sites, content is fetched at build time. If you update a post in Marble, the change won’t be live until you trigger a new deployment. Frameworks like Next.js provide built-in solutions for this, such as Incremental Static Regeneration (ISR), which can be triggered on-demand by a webhook for instant updates.Automating workflows
Create a serverless function that listens for apost.published event from a Marble webhook. When triggered, your function can:
- Send a newsletter to your subscribers with the new post
- Share the post on social media
- Sync the content to another service or backup location
Setting up webhooks in Marble
Navigate to Webhooks
In the Marble dashboard, open your workspace, go to Settings, then
choose Webhooks under the Developers section.
Create a New Webhook
Click Create Webhook and fill in the required details:
- Name: A descriptive name for your webhook.
- URL: The endpoint where the webhook payload will be sent.
- Format: Choose JSON, Discord, or Slack.
- Events: Select the events you want to listen for, such as
post.publishedorpost.updated.
Verifying webhook requests
To ensure that incoming webhook requests are from Marble and haven’t been tampered with, you can verify the request using the webhook secret. Here’s an example of how to verify a webhook request in Next.js using thecrypto module:
If you want a better guide on how to invalidate cache in your framework of
choice, you can check out our blog post on Using Marble’s Webhooks with the
Next.js App Router.
x-marble-signature header of the request. You can use this signature to verify the authenticity of the request. Make sure to add the process.env.MARBLE_WEBHOOK_SECRET environment variable.
Request Payload
When a webhook is triggered, Marble sends a POST request to the specified URL with a JSON payload. JSON webhooks receive a stable envelope that includes the event metadata, the affected resource, the actor when available, and event-specific data. Webhook requests include these headers:x-marble-event: The event type, such aspost.updated.x-marble-event-id: The ID of the workspace event.x-marble-delivery-id: The ID of the delivery attempt.x-marble-timestamp: The Unix timestamp for the request.x-marble-signature: The HMAC SHA-256 signature for the request body.
- Published
- Updated
- Deleted
post.published, post.updated, post.deleted, tag.created, category.updated, author.deleted, and other JSON events. The type, resource, and data fields change to match the event.
Post payloads include id, title, slug, description, coverImage, status, featured, categoryId, primaryAuthorId, publishedAt, createdAt, and updatedAt. Update events also include changes, an array of field names that changed.
Category and tag payloads include id, name, slug, description, createdAt, and updatedAt. Author payloads include profile fields such as name, slug, bio, role, image, email, and socials. Media payloads use name and media metadata such as url, alt, type, size, mimeType, dimensions, duration, and blurHash.
Event Types
Marble supports a variety of event types that you can listen for with webhooks. Here are the currently available events:post.published: Triggered when a post is published.post.unpublished: Triggered when a post is unpublished.post.updated: Triggered when a post is updated.post.deleted: Triggered when a post is deleted.tag.created: Triggered when a new tag is created.tag.updated: Triggered when a tag is updated.tag.deleted: Triggered when a tag is deleted.category.created: Triggered when a new category is created.category.updated: Triggered when a category is updated.category.deleted: Triggered when a category is deleted.media.uploaded: Triggered when a media file is uploaded.media.updated: Triggered when a media file is updated.media.deleted: Triggered when a media file is deleted.author.created: Triggered when a new author is created.author.updated: Triggered when an author is updated.author.deleted: Triggered when an author is deleted.