Developer Documentation

API Contract Review

API Contract Stability Review

Endpoint Consistency

Most endpoints use /v1, noun-based route groups, JSON request/response bodies, and standard status codes. Partner endpoints use API keys, while mobile/admin/dashboard endpoints use bearer tokens.

Response Format

Success responses follow success, message, data, meta. Error responses follow success, message, error.code, error.details.

Risk: a few older placeholder endpoints may return minimal objects. Mobile apps should consume documented fields only.

Error Codes

Error codes are uppercase snake case. Some older aliases exist (INVALID_TOKEN vs future TOKEN_EXPIRED). Keep registry stable and avoid renaming inside /v1.

Authentication

• Bearer JWT for users/admin/mobile/dashboard.
• X-SikaaHub-Key for partner/developer APIs.
• Webhook signatures for inbound provider webhooks.

Pagination

High-volume lists use cursor or limit-based patterns. Future versions should standardize cursor shape across all list endpoints.

Naming

Public IDs are exposed as id, payment_id, transaction_id, etc. Internal numeric IDs should not be returned except legacy/admin operational contexts; review before production.

Compatibility Risks

• Mobile app required fields must not change inside /v1.
• Partner API scope requirements must remain stable.
• Webhook event names and payload shapes need changelog entries for every change.
• Future breaking changes should move to /v2.