



Have any questions? We’re here to help You
Makini's unified API acts as a common denominator across all connected systems. We map each system's data structure to a standardized data model, exposing consistent endpoints regardless of the underlying platform. This means you write the same code to retrieve purchase orders from SAP, NetSuite, or Dynamics—the API calls and response formats are identical. You always get data in the same structure, making it easy to build consistent business logic. The unified approach eliminates the need to learn each system's unique API, manage multiple authentication methods, or handle varying data formats.
Connection credits are Makini's billing unit. Each system integration consumes a specific number of credits based on complexity. Systems are divided into three tiers: Tier 1 (simple systems like cloud CMMS), Tier 2 (mid-complexity ERP systems), and Tier 3 (complex systems like SAP). On-premises installations require double the credits of their cloud equivalents. For example, a cloud SAP S4/HANA connection might use 4 credits, while an on-premises SAP ECC installation uses 8 credits. Connection credits are consumed when you establish a connection and are returned to your pool when you disconnect. This allows flexible allocation across customers—you're not locked into specific connections.
Industrial systems are often heavily customized, and Makini is built to handle this. For reading data, Makini can access virtually any field or custom table in connected systems. Through the connection settings interface, you can specify custom fields, tables, or entities to include in API responses. These show up alongside standard fields in the unified model. For custom objects not in our default model, you can request them through the interface and they'll be available immediately. For writing data, customization support varies by system but covers most common scenarios. During implementation, we work with you to identify required customizations and ensure they're properly configured before going live.
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.
