Skip to main content

Overview

The Dükkango API uses token-based authentication with access tokens that are valid for 24 hours.
All API requests must include the Access-Token header except for the /auth/login endpoint.

Authentication Flow

1

Call Login Endpoint

Send a POST request to /auth/login with your credentials.
2

Receive Access Token

Store the access_token and expiration_date from the response.
3

Include Token in Requests

Add Access-Token header to all subsequent API calls.
4

Refresh Before Expiry

Obtain a new token before the current one expires (24 hours).

Login Endpoint

string
required
Your application secret key provided by Dükkango
string
required
Your restaurant secret key (unique per vendor/branch)

Request

Success Response (200)

Error Response (401)

Using Access Tokens

Once you have an access token, include it in the header of all API requests:

Token Expiration

Access tokens expire after 24 hours. Make sure to handle token expiration gracefully.
When your token expires, you’ll receive a 401 Unauthorized response:

Security Best Practices

  • Never hard-code secret keys in your source code
  • Use environment variables or secure key management systems
  • Encrypt credentials at rest
  • Rotate keys periodically
  • Store tokens in memory, not in local storage (for web apps)
  • Never log tokens in plain text
  • Transmit tokens only over HTTPS
  • Implement token refresh logic
  • Log all authentication attempts
  • Set up alerts for repeated failed logins
  • Monitor unusual API usage patterns
  • Revoke compromised tokens immediately
  • All API calls must use HTTPS (SSL/TLS)
  • Validate SSL certificates
  • Don’t allow HTTP fallback

Multi-Branch Access

A single API key can be configured for vendor-wide access (all branches) or branch-specific access.
When you call /restaurants/get, you’ll see all branches accessible with your API key:

Error Codes

Next: API Reference

Now that you’re authenticated, explore the available API endpoints