




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.
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.
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.
Makini uses cursor-based pagination for retrieving large datasets. API responses include a `next_cursor` field when additional results are available. To retrieve the next page, include the cursor value in your next request: `GET /api/v1/purchase-orders?cursor=CURSOR_VALUE`. Cursor-based pagination is more reliable than offset-based pagination because it handles data changes between requests—if records are added or deleted while you're paginating, you won't miss records or see duplicates. Page size is configurable up to a maximum limit (typically 100-500 records per page depending on entity type). For optimal performance, use the largest page size your application can handle efficiently. The API response also includes total count when available from the source system.
