Lovable Events & Hooks: connect other services without security risks

What Lovable has added

On 27 October 2026, Lovable announced Events & Hooks in its changelog. The feature allows administrators and owners of workspaces on the Business and Enterprise plans to connect Lovable to their own service through an HTTPS endpoint.

This is importantly different from letting a user press a button in your app. Lovable initiates the call itself when something happens in the workspace or when an action needs to be reviewed.

Events are sent after something has happened. For example, Lovable can notify your service when a project is created, published, moved to another workspace or deleted. This is suitable for tasks such as updating an internal project register, starting a review process or notifying another system about a publication.

Hooks run before an action is allowed to continue. The hook described at launch reviews a message before it is sent in a project's chat. Your endpoint can allow or deny the message, for example after checking for personal data, secrets or other sensitive information.

The difference can be summarised as follows:

• An event reports that something has already happened.
• A hook asks whether something is allowed to happen.

This also brings different risks. A failed event can normally be dealt with later. A slow or broken hook, however, can stop someone in the middle of their work. You therefore need to treat events as reliable message handling and hooks as part of Lovable's user flow.

The feature is not the same as a complete security layer covering all use of Lovable. The message hook covers project chat, but not every other route a message may take. Examples that are not covered include calls through the Lovable API or MCP, some standalone chats, voice input and some project flows. If the aim is to prevent sensitive information from reaching external services, you therefore need to review the entire information flow rather than simply enabling a hook.

The security boundary lies with the recipient

Lovable signs its calls with a secret associated with the destination. The signature allows your server to check that the content really comes from Lovable and has not been changed in transit.

It is not enough for the endpoint address to be difficult to guess. A public URL can be discovered, leaked through logs or called by someone trying to impersonate Lovable. Your code must verify the signature before it reads data, starts jobs or makes a decision.

Verification must use the unchanged raw request body received by the server. If a framework first parses the JSON and then creates a new text representation, characters, ordering or whitespace may change. You are then no longer verifying the exact content that was signed.

A secure recipient should therefore work in this order:

• Read the request body as raw text or raw bytes.
• Retrieve Lovable's signature headers.
• Verify both the signature and that the timestamp is current.
• Reject the call immediately if verification fails.
• Parse the JSON only after successful verification.
• Check the event type, workspace and project before performing any action.

Lovable uses the Standard Webhooks format and recommends its verification libraries. Using an established library is safer than assembling the signature string and comparing cryptographic values yourself.

Store the signing secret in the server environment, for example as an environment variable or in a secrets service. It must not appear in the Lovable app's client code, the Git repository or ordinary application logs. The secret is shown when the destination is created and cannot be retrieved or rotated from there. If it is lost or suspected of having leaked, the destination needs to be replaced.

You can also configure a bearer token. Treat it as an additional layer, not as a replacement for signature verification. You should also restrict the endpoint's technical identity. A recipient that only needs to add a row to a register does not need permission to read the entire database, publish apps or administer workspaces.

Build events for reliable delivery

Events are sent asynchronously and may be delivered again if the recipient does not respond as expected. The same event may therefore reach your endpoint several times. Deliveries may also arrive in a different order from the one in which the events occurred.

This is normal for webhooks and should be handled in your design. The code must be idempotent, meaning that the same call can be processed again without creating another unwanted effect.

For example, if a publication event creates a review case, a repeated delivery must not create another identical case. Store webhook-id in a table or other persistent storage and record when the delivery has been received and processed. Lovable retains the same delivery ID for retries, making it useful for deduplication.

It is helpful to separate receiving the work from performing it:

• The endpoint verifies the call.
• It records the delivery and places the work in a queue.
• It responds to Lovable with a successful HTTP status.
• A separate process performs the integration.
• Results and errors are stored for follow-up.

This reduces the risk of Lovable interpreting a slow external system as a failure. It also makes retries easier to control. If, for example, a CRM or internal API is unavailable, the job can remain in the queue without making the entire webhook recipient unavailable.

Event data is deliberately limited and mainly contains identifiers and timestamps. Do not assume that the payload contains everything you need. If the recipient needs to retrieve more information, this should be done through a separate integration with restricted permissions and a clear check that the project is still in the correct workspace.

You should also tolerate future additions. Lovable recommends that the recipient ignore unknown JSON fields. Validate the fields you need, but do not let a new optional field cause every delivery to fail. The event type itself, such as project.published.v1, should, however, be handled explicitly so that a new type does not accidentally trigger the wrong logic.

Treat hooks as a real-time barrier

Hooks are more sensitive because Lovable waits for your decision. The recipient should respond quickly with allow or deny and can provide a clear reason if the message is denied. Hooks are not retried in the same way as events.

When creating the destination, you choose what should happen if the hook encounters a technical error. Fail closed behaviour blocks the action when your service cannot make a decision. This provides stricter control but means that an operational problem in your service may stop messages in the workspace. Fail open behaviour allows the action to continue when an error occurs, providing better availability but a weaker security boundary.

The choice should be based on the risk the control actually addresses. A rule that prevents serious secrets from leaving the organisation may need to block when there is uncertainty. A non-binding quality check should rarely be allowed to stop the entire workspace because an external classification service is unavailable.

The hook payload may contain the entire message as well as information about the sender and attachments. Attachment links are temporarily accessible to anyone who has the link. You should therefore treat both the content and the links as sensitive data:

• Do not log entire messages by default.
• Do not pass the content to more services than necessary.
• Do not store attachments without a clear purpose and retention policy.
• Restrict who can read error reports and review results.
• Use separate test data when developing the flow.

If you use a language model to classify messages, the text must be treated as untrusted input. A message may contain instructions that attempt to influence the classifier. Keep fixed security rules outside the prompt, minimise the context given to the model and do not let the model's response directly start privileged actions.

Also give the user a useful denial message. Explain what needs to be removed or changed without revealing internal detection rules. A generic error often leads to repeated attempts, while a specific explanation makes the control easier to follow.

Check this before connecting production systems

Before connecting a Lovable workspace to real internal systems, you should be able to tick off the following:

• The endpoint uses HTTPS and only accepts the intended method.
• The signature is verified against the raw request body.
• Old or invalid timestamps are rejected.
• The signing secret exists only in a secure server environment.
• The workspace and project identifiers are checked.
• Unknown event types are rejected or safely ignored.
• New optional JSON fields are tolerated.
• Events are deduplicated using webhook-id.
• Slow work runs after the event has been acknowledged.
• The recipient can handle deliveries arriving in an unexpected order.
• The hook's failure behaviour is a deliberate business decision.
• Monitoring is in place for errors, queues and denied messages.
• Logs do not contain message text, attachment links or secrets unnecessarily.
• The service account has the minimum possible permissions.
• The destination can be disabled without a new deployment.
• Testing covers duplicate events, invalid signatures and unavailable dependencies.

Start by testing with a separate destination and a project that contains no real personal data or production secrets. Check the delivery history in Lovable and compare it with the recipient's logs. You should be able to trace a call from receipt to a completed or cancelled action without having to store all the sensitive content.

Also decide who owns the integration after launch. Someone needs to respond when certificates expire, secrets are suspected of having leaked, rules block the wrong messages or an external system changes its API. Events & Hooks is not just a setting in Lovable – it is a new production integration that needs operations, access control and an incident plan.

When a Lovable prototype is ready to affect real data and workflows, the integration needs to be treated as the step from prototype to product.

---

Source: Lovable changelog