Syncing DB with Builder.io – Problem with Deleted Entities

Technical Questions
1

Hi, I am trying to implement storing data from the webhook to my personal DB. When I publish/unpublish content it is pretty straight forward:

  • webhook operation: publish → create/update data in DB
  • webhook operation: unpublish, archive, delete → remove record from the DB

There we can have corner case when webhook will not reach my BE or it will throw some error, or my BE is down. In this case data in the DB will be not updated.

I will have mismatch between Builder data and data in the BD.

In this case I will sync data between DB and builder every 15 minutes. To update to the latest state.

But if I will delete entity from Builder and webhook for some reason will not reach my BE, I will have missmatch and I will not know about this, because we can’t GET deleted Entities from Builder API.

I need advice how to implement checking missmatch for deleted entries. How this can be implemented? Is this even possible?

It will be possible to do if for my space I will have webhook_logs api, but I didn’t found any information about this

2

Hello @Ihor,

You’re correct that handling publish/unpublish/archive is straightforward, but hard deletes are trickier because deleted entries are no longer accessible via the API. If a webhook is missed, there’s no direct way today to query Builder for “all deleted items” or replay webhook history (there isn’t currently a webhook_logs API).

Options to work around this today

  1. Prefer archive over delete
    Many teams use “archive” (or a custom isDeleted flag) instead of hard deletes. Archived content is still queryable through the API, which means your scheduled sync can detect and reconcile changes. If you need permanent deletion, you can purge both in Builder and in your DB after a retention period.

  2. Scheduled sync with ID comparison
    During your 15-minute sync, you can fetch all entries of a given model via the Content API. Compare those IDs with what’s in your DB. Any IDs present in your DB but missing from Builder’s response indicate a mismatch — likely due to a missed delete event. While this doesn’t tell you “why” the record is gone, it gives you a way to detect and reconcile differences.

  3. Add a reliability layer for webhook delivery
    Builder webhooks are delivered once (fire-and-forget). If your backend needs stronger guarantees, consider introducing a lightweight relay endpoint that always acknowledges Builder’s webhook and pushes it to a durable queue (e.g. AWS SQS, Kafka, RabbitMQ). Your downstream service can then process from the queue and retry safely if your DB is down.

We agree that a webhook_logs or event replay API would make this much easier. If this would help your use case, we’d encourage you to submit a feature request here: https://ideas.builder.io/ideas/ — our product team actively reviews requests to help prioritize future improvements.

Thanks