Skip to main content

Overview

Replyke is designed to simplify the development and implementation of social interaction features by offloading much of the backend work. This allows developers to focus on the frontend experience and reduces complexity. Unlike traditional architectures where all interactions pass through a central server, Replyke communicates directly with the client. You can regard Replyke as an opinionated server-as-a-service.

Validation Challenges

This approach reduces complexity for developers but introduces unique challenges in ensuring that data remains valid across various custom use cases—especially when dealing with free-form metadata and content validation. Replyke addresses many common validation needs out of the box, such as enforcing data ownership, managing user authorization, and implementing logical constraints like limiting users to a single vote per entity/comment.

Webhook Solution

However, for application-specific validation—particularly for custom metadata or complex entity rules—developers need a way to extend Replyke’s built-in capabilities, so they can verify their own unique data structures.
To solve this, Replyke leverages a webhook-based system. Developers can define custom validation logic by exposing a webhook on their server, which will be triggered during certain events that might require extra validation. Those events are: Entity creation or update, and User creation or update. This ensures that all relevant data is validated on the developer’s server before the operation is finalized in Replyke. The webhook response determines whether the operation proceeds or is rejected by Replyke, allowing for fine-grained control over data integrity.
By default, no webhooks are configured for new projects, meaning that no further validation takes place beyond Replyke’s built-in validation. While this might be sufficient for development, exposing a webhook is highly recommended for applications in production that require enhanced security and data validation to maintain the integrity of their data.

Webhooks for Validation

In Replyke’s dashboard developers can set up their webhook under settings. A single webhook is enough, and each payload includes a “type” field to help developers know which event the payload is associated with, and how to handle it. A single shared secret from the Replyke dashboard is sufficient for all webhooks.
It is recommended to periodically rotate the secret for enhanced security.
For reference, the setup for validation webhooks is similar to the notifications webhook integration described in App Notifications Webhook Integration, with the added requirement of sending a signed response. Failure to send a response would lead to Replyke rejecting the operation entirely.

Validation Webhook Endpoints

  1. User Created This webhook validates user details before a user is created. The payload includes the following fields:
  2. User Updated This webhook validates user details before a user is updated. The payload structure is similar to the one used for user creation but includes only the updated fields within the data object.
  3. Entity Created This webhook validates entity details before an entity is created. The payload includes the following fields:
  4. Entity Updated This webhook validates entity details before an entity is updated. The payload structure is similar to the one used for entity creation but includes only the updated fields within the data object.

HMAC Signature and Security

To ensure secure communication between Replyke and your server, each webhook request includes an HMAC signature. This signature verifies the authenticity of the request and prevents tampering. The HMAC signature is calculated using the shared secret and the payload.

Supporting Functions

These utility functions handle HMAC validation and response signing for webhook security.
Here are supporting functions for HMAC validation and response signing:

Example Implementation

This example demonstrates complete webhook implementations and supporting functions, ensuring secure and accurate handling of data. Developers using other languages should replicate the HMAC signature logic to maintain compatibility.