Partner Reseller API

All endpoints except the token endpoint itself require a Bearer access token in the Authorization header. The long-lived API key you were issued (esim_live_...) is never sent on these calls directly — it is only ever used once, to obtain a token.

1.1 Exchange your API key for an access token

POST /api/v1/partner/auth/token
Content-Type: application/json

{
  "api_key": "esim_live_1a2b3c4d5e6f7g8h..."
}

{
  "access_token": "eyJhbGciOiJIUzI1NiIs...",
  "token_type": "bearer",
  "expires_in": 3600
}

1.2 Use the token on every other call

GET /api/v1/partner/me
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

• 401 if the token is missing, malformed, expired, or was issued for a different purpose — a regular customer login token cannot be used here, and this token cannot be used against the regular customer-facing API either.
• If your key is revoked by an admin, tokens already issued for it stop working on their very next use — you don't have to wait out the full hour.

Full flow example

TOKEN=$(curl -s -X POST https://triptel.co/api/v1/partner/auth/token \
  -H "Content-Type: application/json" \
  -d '{"api_key": "esim_live_..."}' | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")

curl -s https://triptel.co/api/v1/partner/me \
  -H "Authorization: Bearer $TOKEN"

All request/response bodies are JSON. Every endpoint below requires the Bearer token from §1.2.

[
  {
    "id": 1,
    "iso2": "US",
    "iso3": "USA",
    "name_en": "United States",
    "name_bn": null,
    "flag_url": "https://...",
    "region": null,
    "is_popular": true,
    "is_active": true
  }
]

[
  {
    "id": "a1b2c3d4-...",
    "country_id": 1,
    "title_en": "1GB / 7 Days",
    "title_bn": null,
    "data_amount_gb": 1.0,
    "validity_days": 7,
    "retail_price": 4.50,
    "currency": "USD",
    "is_unlimited": false,
    "is_active": true,
    "coverage_networks": null
  }
]

{
  "business_name": "Acme Travel Co",
  "commission_rate_pct": 5.00,
  "wallet_balance": 142.5000,
  "wallet_currency": "USD",
  "webhook_configured": true
}

{
  "product_id": "a1b2c3d4-...",
  "customer_reference": "your-internal-order-id-123"
}

{
  "order_id": "e5f6a7b8-...",
  "order_no": "PTR-20260904-A1B2C3",
  "status": "PROCESSING"
}

{
  "order_id": "e5f6a7b8-...",
  "order_no": "PTR-20260904-A1B2C3",
  "customer_reference": "your-internal-order-id-123",
  "status": "PROCESSING",
  "iccid": null,
  "lpa_string": null,
  "qr_code_data": null,
  "is_mock_fallback": null,
  "created_at": "2026-09-04T12:00:00Z"
}

{ "webhook_url": "https://yourapp.example.com/webhooks/esim" }

{
  "webhook_url": "https://yourapp.example.com/webhooks/esim",
  "webhook_secret": "whsec_...",
  "warning": "Store this secret securely - it will not be shown again in full."
}

{ "webhook_url": null, "webhook_secret": null }

If you have a webhook_url configured, we POST to it once your order reaches a terminal state (COMPLETED or FAILED).

Delivery attempts: one immediately when the order finishes processing; if that fails (non-2xx response, timeout, connection error), a retry sweep runs every 5 minutes and tries again, up to 3 attempts total. There's no dead-letter queue after that — poll GET /orders/{id} if you suspect a delivery was missed.

Payload

{
  "order_id": "e5f6a7b8-...",
  "customer_reference": "your-internal-order-id-123",
  "status": "COMPLETED",
  "iccid": "8988212345678901234",
  "lpa_string": "LPA:1$rsp.truphone.com$MATCHID123",
  "qr_code_data": "LPA:1$rsp.truphone.com$MATCHID123",
  "is_mock_fallback": false
}

On a FAILED order, the eSIM fields are all null — check status first.

Signature verification

Every delivery includes an X-Webhook-Signature header: the HMAC-SHA256 of the exact raw request body, hex-encoded, using your webhook_secret.

import hmac, hashlib

def verify_webhook(raw_body: bytes, signature_header: str, webhook_secret: str) -> bool:
    expected = hmac.new(webhook_secret.encode(), raw_body, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, signature_header)

Always verify against the raw bytes of the request body, before any JSON parsing — re-serializing and re-hashing a parsed-then-reserialized payload is not guaranteed to match byte-for-byte.

A 429 response means you've hit the limit — back off and retry after a short delay. Limits are keyed to your specific API key (via the token), not your IP, except for the token endpoint itself (which has no partner identity yet).

Standard HTTP status codes; error detail is always in the JSON body's detail field:

{ "detail": "Insufficient wallet balance. Please top up." }

Key issuance and revocation are Super-Admin-only actions performed from the internal admin console — there is no self-service signup. If you're a merchant looking to integrate programmatically, contact your account admin once your partner application is approved.

If you suspect your key has leaked, ask for immediate revocation — any access tokens already issued from it stop working on their next use, not just after they naturally expire.