



Have any questions? We’re here to help You
All API requests require authentication via bearer token. After successfully connecting a system through Makini's authentication module, you receive an API token. Include this token in the Authorization header of your requests: `Authorization: Bearer YOUR_API_TOKEN`. Each connection has a unique token, allowing you to manage multiple customer connections independently. Tokens remain valid as long as the underlying system credentials are valid and the connection is active. If a customer changes their system credentials, you'll need to reconnect to obtain a new token.
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's API supports date filtering on most endpoints using query parameters. You can filter by creation date, modification date, or entity-specific date fields like order date or delivery date. Common patterns include `modified_after=2024-01-01` to retrieve records updated since a specific date, or relative timestamps like `modified_after=2024-01-01T00:00:00Z`. For optimal performance, use incremental data retrieval patterns rather than repeatedly fetching all records. The sync status endpoint provides the last sync timestamp, which you can use as the `modified_after` value for your next query. This approach minimizes data transfer and API load while ensuring you capture all changes.
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.
