



Discourse is a modern, open-source discussion platform designed for online communities, forums, and knowledge sharing, offering threaded topics, moderation tools, trust levels, and APIs for extensibility and integrations.
Have any questions? We’re here to help You
Makini implements automatic retry logic for failed webhook deliveries. If your endpoint is unavailable or returns an error status code, we retry delivery with exponentially increasing intervals starting at 30 seconds. Retries continue for up to 24 hours. If delivery ultimately fails, the webhook is logged but not delivered. You can view failed webhooks in the Makini dashboard and manually retry them. To prevent webhook loss during extended downtime, implement a polling backup strategy—periodically check the sync status and query for recent changes if no webhooks have been received within the expected time window. Design your webhook receiver to be idempotent, as retry logic may result in duplicate deliveries.
Yes, through a combination of sandbox environments, test data, and Makini Flows. For testing different data states, use sandbox connections with predefined test scenarios. For testing system behavior like delays, errors, or specific responses, you can build test workflows in Makini Flows that simulate various scenarios. For testing with actual systems, set up dedicated test instances of your target systems. During implementation, we work with you to identify critical test scenarios and ensure your testing environment supports them. For specific edge cases or unusual system configurations, we can help create custom test scenarios.
Write operation limitations vary by system. Common limitations include: field-level restrictions (some fields may be read-only), business rule validation (orders may require certain fields or valid vendor codes), permission requirements (the connected account needs specific permissions), timing restrictions (some systems prevent modifications after certain workflow states), and rate limits on write operations. Custom fields in target systems may not be writable through standard APIs. Some systems have transactional requirements—for example, purchase order line items must be created in the same transaction as the order header. During implementation, we identify write operation limitations for your specific use cases and design workflows that work within those constraints.
When a system becomes unavailable, Makini detects the connectivity failure and marks the connection status accordingly. Scheduled syncs will fail with connectivity errors. API requests to the connection will return error responses indicating the system is unreachable. Makini continues attempting scheduled syncs using exponential backoff—initial retries happen frequently, then progressively less often to avoid overwhelming the system when it comes back online. Webhooks notify you of the connection status change. When the system comes back online, normal operations resume automatically. For temporary outages, no action is required. For extended outages, you may want to notify the customer. Connection credits remain consumed during outages since the connection configuration persists.
