




Have any questions? We’re here to help You
Makini is SOC 2 Type 2 compliant and undergoes penetration testing twice annually. We use industry-standard encryption protocols including TLS 1.2+ for data in transit and AES-256 for data at rest. Customer credentials are encrypted using secure key management practices. Our infrastructure follows security best practices including network segmentation, access controls, and regular security audits. For highly regulated industries or customers with strict compliance requirements, we offer self-hosted deployment options that keep all data within your infrastructure. We've successfully met security requirements for enterprises including financial institutions and government contractors.
Yes, Makini provides extensive customization options for field mappings. Through the connection settings interface, you can view how each system's fields map to Makini's unified model. You can remap fields, add custom field mappings, or create entirely new custom fields that will appear in API responses. These customizations are connection-specific, allowing different mapping configurations for different customers. Mapping changes take effect immediately without requiring code changes. For standardized workflows, default mappings typically provide sufficient coverage. Custom mappings are most useful when integrating with heavily customized systems or when you need fields beyond the standard unified model.
Webhooks allow Makini to notify your application of events in real-time. To set up webhooks, configure a webhook URL in your connection settings or during the initial connection flow. Your webhook endpoint must accept POST requests, respond within 10 seconds with a 200 status code, and use HTTPS with a valid SSL certificate. Makini will send webhook payloads to your endpoint when configured events occur, such as sync completion, connection status changes, or errors requiring attention. We recommend keeping your webhook receiver lightweight—ideally just writing the payload to a queue for asynchronous processing—to avoid timeouts and ensure reliable delivery.
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.
