




Have any questions? We’re here to help You
The initial sync occurs when you first connect a system and retrieves historical data to establish a baseline. This includes records from a configurable time period (typically 30-90 days) and can take several minutes to hours depending on data volume. Initial syncs are complete snapshots of the requested data. Incremental syncs occur on subsequent runs and retrieve only records created or modified since the last successful sync. Makini tracks sync timestamps and uses them to query for changes efficiently. Incremental syncs are much faster, usually completing in seconds to minutes. This approach minimizes API load on source systems while keeping your data current.
Design your webhook receiver to handle duplicates and out-of-order webhooks, as network issues or retries can cause both scenarios. Keep the receiver lightweight—ideally writing incoming webhooks to a queue or reliable storage—then process them asynchronously. This prevents timeouts and allows your system to handle high-volume webhook spikes. Respond with a 200 status code immediately after receiving the webhook, before processing begins. Implement idempotency by tracking processed webhook IDs and skipping duplicates. Use constant-time comparison for signature verification to prevent timing attacks. If webhook processing fails, log the error but still return 200 to prevent unnecessary retries. Set up monitoring and alerts for webhook failures so you can investigate issues promptly. For critical workflows, combine webhooks with periodic polling as a fallback mechanism.
500-level errors indicate issues on Makini's side or with the connected system. These are typically temporary and retrying the request after a brief delay often succeeds. Implement exponential backoff for retries—wait a few seconds, then progressively longer intervals. If errors persist beyond a few retries, check the Makini status page for service disruptions. The error may also stem from the connected system experiencing issues rather than Makini itself. For persistent 500 errors, contact support with the request ID from the error response. Include details about when the error started, which operations are affected, and which connections are impacted. Our support team can quickly identify whether the issue is systemic or connection-specific.
Yes, Makini supports write operations including creating, updating, and in some cases deleting records in connected systems. Common write operations include creating purchase orders, updating work order status, modifying inventory levels, and creating vendor records. Write support varies by system and entity type—core entities like purchase orders have comprehensive write support across major systems, while more specialized entities may have limited write support in some systems. Write operations use the same unified API, so the code to create a purchase order in SAP is identical to creating one in NetSuite. Validate write requirements during implementation to ensure your target systems support needed operations.
