




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.
API tokens must be stored securely and should never be exposed on the client side or in public repositories. Store tokens in secure environment variables or dedicated secrets management systems like AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault. Never hardcode tokens in application code or commit them to version control. Implement proper access controls so only authorized services can access stored tokens. For production environments, use separate tokens from development/testing environments. Rotate tokens periodically and immediately revoke tokens if you suspect they've been compromised. Makini tokens provide access to customer data, so treat them with the same security standards you'd apply to database credentials.
Makini implements automatic retry logic for failed webhook deliveries. If your endpoint is unavailable or returns an error status code, we retry delivery with exponentially increasing intervals starting at 30 seconds. Retries continue for up to 24 hours. If delivery ultimately fails, the webhook is logged but not delivered. You can view failed webhooks in the Makini dashboard and manually retry them. To prevent webhook loss during extended downtime, implement a polling backup strategy—periodically check the sync status and query for recent changes if no webhooks have been received within the expected time window. Design your webhook receiver to be idempotent, as retry logic may result in duplicate deliveries.
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.
