To access merchant data (products, orders, store information, etc.), Keeta mandates that developer applications obtain explicit merchant authorization via access tokens. This ensures compliance with data security and privacy regulations:
- Chain Brands: All stores under a single brand share one access token.
- Independent Stores/Single Locations: Each store maintains a unique access token.
Self-Service Authorization
Follow the Merchant Self-Authorization Integration Guide to programmatically generate tokens.
Keeta Team Assistance
Contact Keeta Team for manual token provisioning.
Token Response Example:
| Parameter | Description | Example |
|---|---|---|
| accessToken | Authorization credential | 361d6d7f2624497e9976073205c16227 |
| tokenType | Token format | bearer |
| expiresIn | Validity period (seconds) | 7776000 (90 days) |
| refreshToken | Token renewal credential | 223e556762ee42a78907d143ee9e83e7 |
| scope | Permission scope | all (default) |
| issuedAtTime | Issuance timestamp (milliseconds) | 1703147284319 |
{
"accessToken": "361d6d7f2624497e9976073205c16227",
"tokenType": "bearer",
"expiresIn": 7776000,
"refreshToken": "223e556762ee42a78907d143ee9e83e7",
"scope": "all",
"issuedAtTime": 1703147284319
}- Time-Bound Validity: Both accessToken and refreshToken share identical expiration timelines (90 days).
- Proactive Management: Monitor token expiration and initiate refresh 3-5 days before expiry.
// Refresh Curl Example
curl -X POST 'https://open.mykeeta.com/api/open/base/oauth/token' \
-H 'Content-Type: application/json' \
--data-raw '{
"appId": 123456,
"refreshToken": "223e556762ee42a78907d143ee9e83e7",
"timestamp": "1715687158",
"grantType": "refresh_token",
"sig": "10bca710d855804308011a66d2ccd7ddaaa06f38307431a77745c6c7f669dd5a"
}'Keeta's token management system requires developers to maintain strict vigilance over the expiration timelines of both access tokens and refresh tokens, as these credentials share identical validity periods and will simultaneously become invalid once they reach their expiry.
When encountering failures during token refresh attempts, whether due to network instability, system anomalies, or transient errors, developers must implement a structured retry strategy with 3 to 5 sequential attempts before escalating the issue. If persistent failures occur despite these retries, immediate engagement with Keeta's technical support team is required for diagnostic investigation and resolution.
Following a successful token refresh operation, developers must observe critical usage constraints: the newly generated tokens are subject to a strict rate limit prohibiting more than one refresh attempt per minute. Additionally, while the new tokens become immediately operational, the previous tokens retain validity for a 60-minute grace period. This intentional overlap prevents concurrent request failures during the transition window, ensuring seamless continuity for in-flight operations still referencing the original credentials.