This page explains the core integration rules to keep your Kisara API client secure, stable, and predictable in production.Documentation Index
Fetch the complete documentation index at: https://docs.kisara.my.id/llms.txt
Use this file to discover all available pages before exploring further.
Integration Hierarchy
1. Access
Confirm the right auth model first: API key for consumer endpoints and JWT for internal web-session flows.
2. Reliability
Handle traffic spikes with route-aware retries, backoff, and timeout discipline.
3. Contract
Validate envelope fields consistently so client behavior stays predictable.
Operational Summary
Quick Checklist
Auth Header
Ensure protected endpoints always receive X-API-Key from server-side integrations.
Retry Strategy
Handle HTTP 429 with exponential backoff and a clear retry limit.
Response Contract
Validate status_code, message, data, and metadata before downstream processing.
Authentication
Consumer API protected endpoints use API key authentication.JWT bearer tokens are still used for internal web session flows such as login/refresh and API key lifecycle management.
Endpoint Access Model
Consumer API Access
Primary access method is X-API-Key on protected routes used by external integrations.
Internal Session Access
JWT is intended for authenticated web-session operations and account-bound internal flows.
Rate Limiting
The API applies both global and per-route limits to maintain service stability.| Scope | Limit |
|---|---|
| Global (all routes) | 100 requests per IP per minute |
Auth and API key management (/auth/*) | 10 requests per IP per minute |
User profile (/user) | 5 requests per IP per minute |
Message routes (/message/*) | 30 requests per IP per minute |
- If a route has a stricter limit, that route limit is applied first.
- Home routes use the global limit.
- Rate limit keys are based on client IP.
Response Format
Most endpoints return a response envelope like this:Treat this response shape as your main contract. Always validate status_code and metadata on the client side.
Contract Validation Order
Best Practices
Always check status_code
Do not rely on HTTP status alone. Use status_code and message to validate outcomes.
Keep metadata
Log metadata.timestamp and metadata.execution_time_ms for audit and debugging.
Use timeouts
Configure request timeouts on the client so your app does not hang during network issues.
Use idempotency
For sensitive operations, prevent duplicate requests to avoid side effects.
Next Steps
- Continue to API Reference for full parameter and schema details.
- Test endpoints in the API playground to validate integration quickly.
Explore all endpoints
Move to route-level details, request bodies, and response schemas.
Back to docs home
View quickstart, platform endpoints, and recommended onboarding path.