API Overview & Authentication

ADBNK exposes a RESTful HTTP API in four groups:

Group	Prefix	Auth	Description
Advertiser API	/api/advertiser	JWT Bearer	Backend for the advertiser console
Publisher API	/api/publisher	JWT Bearer	Backend for the publisher console
Ad Request API	/ad	None	Real-time ad requests from zones
Event Reporting API	/track	None	Impression / click / conversion reporting

Base URL

The base domain for all endpoints is https://api.adbnk.co. Ad requests and event reporting also have dedicated subdomains js.adbnk.co (SDK) and track.adbnk.co (tracking); examples here use the business domains uniformly.

Authentication

The advertiser / publisher endpoints use JWT Bearer Token auth. First call the corresponding login endpoint to get a token, then carry it in the Authorization header of every request:

Authorization: Bearer <token>

Passing it via the query parameter ?token=<token> is also supported (only for scenarios where you can't set custom headers, such as pixels and iframes).

The token is signed with HMAC-SHA256; the payload includes id (user ID), type (admin / advertiser / publisher), iat, and exp. The default validity is 86400 seconds (24 hours); after expiry you must log in again.

Token type and path must match

An advertiser token can only access /api/advertiser/*, and a publisher token can only access /api/publisher/*; cross-role access returns 401.

Example successful login response:

{
  "code": 0,
  "message": "Login successful",
  "data": {
    "token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9....",
    "token_type": "Bearer",
    "expires_in": 86400,
    "user": { "id": 1, "username": "demo", "email": "[email protected]" }
  },
  "timestamp": 1752200000
}

Unified response envelope

All endpoints return a unified JSON envelope:

{
  "code": 0,
  "message": "success",
  "data": {},
  "timestamp": 1752200000
}

Field	Type	Description
code	int	Business status code; 0 means success, non-zero means failure
message	string	Human-readable message (localized by request language)
data	object/array/null	Business data
timestamp	int	Server Unix timestamp (seconds)

When message comes from an i18n translation key, the response also carries message_key (and optionally message_params) for frontend re-localization.

Dual status codes

code is the primary business signal (0 = success). The HTTP status code is also aligned with code (200 on success, errors mapped to the corresponding 4xx/5xx), making it easy for CDN / WAF / monitoring to recognize error rates.

Error code convention

code reuses HTTP semantics; common values:

code	HTTP	Meaning
0	200	Success
400	400	Bad parameters / validation failure
401	401	Not logged in / invalid or expired token
403	403	Insufficient permission / account disabled / feature off
404	404	Resource not found
412	412	Precondition failed (profile incomplete / KYC not passed)
422	422	Semantic validation failure
429	429	Too many requests
500	500	Server error

Example error response:

{
  "code": 401,
  "message": "Invalid or expired token",
  "data": null,
  "timestamp": 1752200000
}

Pagination convention

List endpoints use these query parameters uniformly:

Param	Type	Required	Default	Description
page	int	No	1	Page number, min 1
page_size	int	No	20	Items per page, range 1–100
sort_field	string	No	id	Sort field (whitelisted per endpoint)
sort_order	string	No	desc	Sort direction: asc / desc

Paginated response structure:

{
  "code": 0,
  "message": "success",
  "data": {
    "list": [],
    "pagination": {
      "total": 135,
      "page": 1,
      "page_size": 20,
      "total_pages": 7
    }
  },
  "timestamp": 1752200000
}

Rate limiting

The platform doesn't apply uniform rate limiting to all endpoints, but it throttles sensitive operations:

• Forgot password: the same email can only request once per 60 seconds; exceeding returns 429.
• Event reporting: impression / click dedup windows are controlled by the admin settings ad.impression_dedup_seconds / ad.click_dedup_seconds; duplicate events within the window aren't billed.

WARNING

Specific thresholds may change with platform configuration; refer to the actual response.

CORS

Cross-origin requests are allowed from *.adbnk.co, localhost, and 127.0.0.1 origins, allowing the headers Content-Type, Authorization, X-Requested-With, Accept, Origin, X-Token. CORS preflight (OPTIONS) handling is enabled for all groups.

---

Continue reading: Advertiser API · Publisher API · Ad Request API · Events & Conversion Reporting