



Have any questions? We’re here to help You
Makini uses standard HTTP status codes and structured error responses. Error responses include an error code (e.g., `AUTHENTICATION_FAILED`, `RATE_LIMIT_EXCEEDED`), error type for categorization, a human-readable error message, and a unique request ID for support inquiries. Common status codes include 400 for invalid requests, 401 for authentication failures, 403 for permission issues, 429 for rate limiting, 500 for server errors, and 503 for service unavailability. Use the error code for programmatic error handling rather than parsing error messages. The request ID helps our support team quickly identify and investigate specific issues.
Testing should cover authentication, data retrieval, data writing, error handling, and workflow logic. Start by connecting a test system through Makini's authentication flow. Use sandbox or non-production instances of your target systems when available. Test API calls for each entity type you'll use (purchase orders, work orders, etc.) to verify data mapping and field coverage. Test error scenarios by providing invalid inputs or attempting operations without proper permissions. For workflow-based integrations, test each workflow step independently before testing end-to-end. Verify webhook delivery and signature verification. Test with realistic data volumes to identify performance issues. Include tests for connection failure scenarios and verify your error handling and retry logic work correctly.
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.
Makini maintains API stability and provides advance notice of breaking changes. The current API version is v1. When we introduce breaking changes, we release a new API version while maintaining the previous version for a transition period (typically 12 months minimum). Non-breaking changes (like adding new fields or endpoints) are introduced into the current version without requiring updates. We announce upcoming version changes through multiple channels: email notifications, dashboard announcements, and release notes. API responses include version information in headers. We recommend specifying the API version explicitly in your requests to ensure consistent behavior. During version transitions, we provide migration guides and support for updating integrations.
