Authentication

GET /api/public/v1/me HTTP/1.1
Host: autoranko.com
Authorization: Bearer ar_live_…

Create a token#

1. Sign in and open Dashboard → API.
2. Under API keys, name the token after where it will live (Zapier, n8n, a script) in up to 80 characters, then click Create token.
3. Copy the token right away. It's shown once: Autoranko stores only a SHA-256 hash of it, so a lost token can't be recovered. Revoke it and create a new one instead.

An account can have up to 10 active tokens. Dashboard → API lists each one with its name, its first 15 characters (such as ar_live_3f9a1c7…) and the day it was last used.

Token format#

A value that doesn't start with ar_live_ is rejected before any lookup, with 401 invalid_token (Invalid token format.). The keys the WordPress plugin uses internally aren't API tokens and get the same error.

Send the token#

Put the token in the Authorization header with the Bearer scheme, on every request: there are no sessions, cookies or query-string tokens. The quickest check is GET /me, which returns the account the token belongs to.

curl https://autoranko.com/api/public/v1/me \
  -H "Authorization: Bearer $AUTORANKO_TOKEN"

const res = await fetch("https://autoranko.com/api/public/v1/me", {
  headers: { Authorization: `Bearer ${process.env.AUTORANKO_TOKEN}` },
});
const data = await res.json();
if (!res.ok) throw new Error(`${data.error.code}: ${data.error.message}`);

console.log(`${data.account.email}: ${data.plan} plan, ${data.site_count} site(s)`);

import os
import requests

res = requests.get(
    "https://autoranko.com/api/public/v1/me",
    headers={"Authorization": f"Bearer {os.environ['AUTORANKO_TOKEN']}"},
    timeout=30,
)
data = res.json()
if not res.ok:
    raise RuntimeError(f"{data['error']['code']}: {data['error']['message']}")

print(f"{data['account']['email']}: {data['plan']} plan, {data['site_count']} site(s)")

<?php
$ch = curl_init('https://autoranko.com/api/public/v1/me');
curl_setopt_array($ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_HTTPHEADER => ['Authorization: Bearer ' . getenv('AUTORANKO_TOKEN')],
]);
$data = json_decode(curl_exec($ch), true);
if (isset($data['error'])) throw new RuntimeException($data['error']['message']);

printf("%s: %s plan, %d site(s)\n", $data['account']['email'], $data['plan'], $data['site_count']);

{
  "account": {
    "id": "7776bc52-200e-4df1-b959-0837990dd4e8",
    "email": "demo@autoranko.com",
    "name": "Demo Account"
  },
  "plan": "free",
  "site_count": 1
}

The samples read the token from the AUTORANKO_TOKEN environment variable, so it never appears in your code: export AUTORANKO_TOKEN=ar_live_… in your shell, or your platform's secret settings in production.

Authentication errors#

A missing, malformed, unknown or revoked token gets 401 with one of these codes. Requests rejected with 401 don't count toward the rate limit.

{
  "error": {
    "code": "missing_token",
    "message": "Missing bearer token. Create one in Dashboard → API."
  }
}

What a token can access#

• A token acts as the account that created it. It sees exactly that account's sites, synced articles and jobs, including jobs created in the dashboard.
• Other accounts' sites, jobs and articles answer 404 not_found, never 403: the API doesn't confirm that an ID exists.
• There are no scopes to request. Every token can call every endpoint, except that changing AI models needs an admin token.
• Plan allowances are enforced per site, whichever token makes the call: when a site's articles run out, POST /sites/{id}/jobs answers 429 plan_limit.

Admin tokens#

Admin tokens are ordinary ar_live_ tokens created by an Autoranko administrator account. They work everywhere a regular token does and can also change the platform-wide AI model settings. Nothing marks them in the token itself: the account behind the token decides.

Revoke a token#

In Dashboard → API, click Revoke next to the token. It stops working at once: its next request gets 401 invalid_token (Invalid or revoked token.). A revoked token can't be restored.

Rotate without downtime

1. Create a new token and deploy it alongside the old one.
2. Once your integration runs on the new token, check that its last-used date in Dashboard → API is current.
3. Revoke the old token.

Keep tokens safe#

Anyone holding a token can create and publish articles on your account. Treat it like a password.

• Call the API from your server. It sends no CORS headers, so browsers block calls from other sites anyway: never put a token in front-end JavaScript, a mobile app or a WordPress theme.
• Keep tokens in environment variables or a secrets manager, never in source control or logs.
• Use HTTPS only, and revoke tokens you no longer use.
• If a token leaks, revoke it first, then check GET /sites/{id}/jobs for jobs you didn't create.