




Have any questions? We’re here to help You
Makini maintains a comprehensive data model built from analyzing thousands of industrial systems. When data flows through Makini, we automatically transform it from the source system's format into our standardized structure. For example, purchase orders from SAP, NetSuite, and Dynamics all return with consistent field names, data types, and structures. This normalization happens in real-time as data passes through the API. You also have access to raw data if needed for specific use cases. The unified model covers common entities like purchase orders, work orders, inventory items, vendors, and assets, with extensive field coverage across systems.
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.
Makini provides sandbox connections for testing without affecting production systems. Sandbox connections include sample data representing common scenarios: standard purchase orders, orders with custom fields, orders in various states (draft, approved, completed), and error cases like invalid vendors or out-of-stock items. Sandbox data is read-only for safety—write operations return success responses without modifying data. This allows thorough testing of your integration logic without risk. For testing with specific systems, we recommend using dedicated test instances of the actual systems (like SAP sandbox environments) connected through Makini, which provides the most realistic testing experience.
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.
