API

Why two APIs?

The classic reseller API (v2) that the whole industry uses posts a form to a single endpoint and always answers HTTP 200. That is exactly the shape off-the-shelf panel software expects, so it stays as it is. Developers writing their own systems kept hitting its limits: errors could not be told apart, the catalog arrived in one piece, and order status had to be polled forever. v3 was written for them.

Comparison

Which one should I use?

Getting started

1. 1Create an API key on the Keys tab.
2. 2Fetch the service list and read the id and field schema of the service you need.
3. 3Validate the order with preview first, then create it.
4. 4Register a webhook, or read the event stream, to follow status changes.

Base URL

Every path is appended to this URL. The version lives in the path: if a breaking change is ever needed, a new path (v4) is published and this one keeps working untouched. The release date of the contract is returned in the X-Api-Version header on every response.

https://panelfollows.com/api/v3

Authentication

Send your API key as a Bearer token in the Authorization header. The X-Api-Key header is accepted as an alternative.

GET https://panelfollows.com/api/v3/account
Authorization: Bearer pf_live_...

Your existing legacy key also works on v3, so you can try it right away. Use a v3 key in production: it can be labelled, revoked individually, and is never stored in plain text.

Quick start

curl https://panelfollows.com/api/v3/services?limit=5 \
  -H "Authorization: Bearer YOUR_API_KEY"

Language

Pick the response language with the Accept-Language header or the ?lang= parameter; the parameter wins. Service names, service descriptions, category names, order status labels, order field labels and error messages all come back in that language.

Machine values never change with language: error.code, order.status, service.type and currency are always the same. Branch on those, and show the text to your users.

Accept-Language: tr
# veya
GET https://panelfollows.com/api/v3/services?lang=tr

Request and response format

Request bodies are JSON (application/json); form-urlencoded is also accepted for quick tests. Responses are JSON: a single resource is a plain object, and lists come in an envelope with data, has_more and next_cursor. Every object carries an object field naming its type.

Amounts are decimal STRINGS ("1.2340"), not floats. Parse them into a decimal type on your side so no fractions are lost. The currency is USD.

Timestamps are RFC 3339 (2026-08-21T00:24:45.255Z).

Errors

Failures return a real HTTP status code and a body carrying a single error object. Your code should branch on error.code: that value is stable and never changes with language.

HTTP/1.1 400 Bad Request
Content-Type: application/json
X-Request-Id: req_0c858d8af7f65eca001b2f5a

{
  "object": "error",
  "error": {
    "type": "invalid_request_error",
    "code": "quantity_out_of_range",
    "message": "Miktar, bu servisin izin verdiği aralığın dışında.",
    "param": "quantity",
    "doc_url": "https://panelfollows.com/api-docs#error-quantity_out_of_range",
    "request_id": "req_0c858d8af7f65eca001b2f5a"
  }
}

Rate limits

600 requests per minute per key, plus 900 per minute per IP. Every response carries RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset so you can slow yourself down before hitting the wall. Exceeding the limit returns 429 with a Retry-After header.

Pagination

Lists are cursor-paginated. Send limit for the page size (500 max) and starting_after with the id of the last item on the previous page. Keep going until has_more is false; next_cursor gives you the cursor for the next call. An out-of-range limit is not silently clamped, it errors: silent clamping makes clients believe they fetched everything.

Duplicate protection (Idempotency-Key)

Add a random Idempotency-Key header when creating an order. If the connection drops and you retry with the same key, no second order is created: the first response is returned again, with an Idempotent-Replay: true header. Records are kept for 24 hours.

Sending the same key with a DIFFERENT body returns 409 idempotency_key_reuse. That almost always means key generation is broken on the client side. A failed request does not burn the key: fix the problem and retry with the same one.

Creating an order

curl -X POST https://panelfollows.com/api/v3/orders \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 8f14e45f-ea3a-4b1c-9c1e-2b0d5c6a7e91" \
  -d '{
    "service": 1234,
    "link": "https://instagram.com/username",
    "quantity": 1000
  }'

Service field schema

Every service publishes the fields it needs in a fields array: name, type, whether it is required, its limits, and a label plus description in your language. When a field has determines_quantity set to true, the quantity is derived from the number of lines in it.

// Servisin kendi alan şemasından formu OTOMATİK üretmek:
// hiçbir servis tipini koda gömmeniz gerekmez.
const res = await fetch("https://panelfollows.com/api/v3/services/1234", {
  headers: { Authorization: "Bearer YOUR_API_KEY", "Accept-Language": "tr" },
});
const service = await res.json();

for (const field of service.fields) {
  renderInput({
    name: field.name,
    label: field.label,             // kullanıcının dilinde
    hint: field.description,        // kullanıcının dilinde
    required: field.required,
    type: field.type,               // url | integer | string | text_lines
    min: field.min,
    max: field.max,
    // true ise miktarı bu alanın satır sayısı belirler
    countsLines: field.determines_quantity === true,
  });
}

The service object

{
  "object": "service",
  "id": 1234,
  "name": "Instagram Takipçi | Türk | 30 gün telafi",
  "description": "Gerçek hesaplardan Türk takipçi. Başlangıç 0-1 saat.",
  "type": "default",
  "platform": "instagram",
  "category": { "slug": "instagram-takipci", "name": "Instagram Takipçi" },
  "pricing": {
    "rate": "1.2340",
    "currency": "USD",
    "unit": "per_1000",
    "unit_note": "Fiyat 1000 adet içindir."
  },
  "limits": { "min": 100, "max": 100000 },
  "features": { "refill": true, "cancel": false, "dripfeed": true },
  "average_time_seconds": 4320,
  "fields": [
    {
      "name": "link",
      "type": "url",
      "required": true,
      "label": "Bağlantı",
      "description": "Gönderimin yapılacağı profilin herkese açık adresi."
    },
    {
      "name": "quantity",
      "type": "integer",
      "required": true,
      "label": "Miktar",
      "description": "Kaç adet gönderileceği.",
      "min": 100,
      "max": 100000
    }
  ],
  "is_active": true,
  "updated_at": "2026-08-20T09:15:00.000Z"
}

Order preview (dry run)

POST /orders/preview validates an order and computes its charge WITHOUT creating it. Show the price to your customer and check your balance covers it beforehand. Nothing is debited and no provider is contacted.

Batch orders

POST /orders/batch accepts up to 50 orders in one call. Items are processed in order and each reports its own result: if one fails the rest are still created, and you see exactly which one failed and why.

Embedding related objects

Pass include=service on the order endpoints and the service object is embedded in the response, saving you a second request.

Endpoint reference

OpenAPI schema

A machine-readable definition of every endpoint. Feed this file to a client generator (openapi-generator, Kiota) or to Postman to get a ready client in your own language.

https://panelfollows.com/api/v3/openapi.json

Frequently asked

Endpoint

POST https://panelfollows.com/api/v2
POST https://panelfollows.com/api/v2/tr

Authentication

Every request carries a key parameter. Keep your key secret and regenerate it immediately if it leaks.

Request and response format

Requests are POSTed as a form (application/x-www-form-urlencoded) and responses are JSON. Failures also return HTTP 200, with { "error": "..." } in the body.

Also supported, though never documented before: you can call it with GET, and you can send the body as application/json.

Rate limits

240 requests per minute per key, plus 300 per minute per IP. Excess requests are rejected with 429.

Actions and parameters

Example

curl -X POST https://panelfollows.com/api/v2 \
  -d "key=YOUR_API_KEY" \
  -d "action=add" \
  -d "service=1234" \
  -d "link=https://instagram.com/username" \
  -d "quantity=1000"

# Yanıt: { "order": 23501 }

Turkish responses

Append /tr to the URL to receive service names, categories, order statuses and error messages in Turkish. Parameters, actions and the response shape are identical, and your key works on both URLs. Technical fields (type, refill_status, currency) stay in English for standard compatibility.

Moving to v3

Migration is optional. If you do move, most of your business logic survives because the parameter names are unchanged; what differs is the transport and how you read errors.

1. 1Move the key from the body's key field to the Authorization: Bearer header.
2. 2Call a resource path instead of action=... (POST /orders instead of add).
3. 3Check for failure with the HTTP status and error.code instead of "is there an error field".
4. 4Compare order status against the machine value, not the display text.
5. 5Add an Idempotency-Key when creating orders.
6. 6Replace status polling with webhooks.

v3 keys

Create as many keys as you need, label each one and revoke them individually. Only a cryptographic digest of the key is stored on our side.

Legacy key

The single key used by the classic reseller API (v2). It also works on v3. Regenerating it invalidates the old value immediately.

Security

• Keep the key in an environment variable, never in source code.
• Do not put a key in code that runs in a browser; proxy the calls through your own server.
• Create a separate key per system so revoking one does not affect the others.
• If you suspect a leak, roll out the new key first, then revoke the old one.

Why webhooks?

Polling is both slow and wasteful: asking about thousands of orders every minute eats your rate limit and you still learn about changes minutes late. With webhooks the change reaches you as it happens.

Setup

1. 1Prepare a public https URL (local and private network addresses are rejected).
2. 2Add the URL below and store the signing secret shown once.
3. 3Verify the signature on your side and answer 2xx.
4. 4Use the test button to confirm the whole path end to end.

What we send

POST /hooks/pf HTTP/1.1
Content-Type: application/json
Webhook-Id: evt_7f910fba7cd042ef9d9069ba5c074fa0
Webhook-Timestamp: 1787261223
Webhook-Signature: t=1787261223,v1=9c1e2b0d5c6a7e91...

{
  "object": "event",
  "id": "evt_7f910fba7cd042ef9d9069ba5c074fa0",
  "type": "order.completed",
  "created_at": "2026-08-21T00:27:03.531Z",
  "data": {
    "previous_status": "in_progress",
    "order": {
      "object": "order",
      "id": 23501,
      "status": "completed",
      "status_label": "Tamamlandı",
      "service": 1234,
      "quantity": 1000,
      "start_count": 4210,
      "remains": 0,
      "charge": "1.2340",
      "currency": "USD"
    }
  }
}

Verifying the signature

Every request carries a Webhook-Signature header: t is the timestamp and v1 is the signature. The signature is the HMAC-SHA256 of the string "<timestamp>.<raw body>" using your secret.

1. 1Parse t and v1 out of the header.
2. 2Check that t is no older than 5 minutes, to block replays.
3. 3Compute the HMAC-SHA256 of "<t>.<raw body>" with your secret.
4. 4Compare it to v1 in constant time and reject the request if it does not match.

Verification example

import crypto from "node:crypto";
import express from "express";

const app = express();
// ÖNEMLİ: imza HAM gövde üzerinden hesaplanır. JSON'a çevirip yeniden
// dizeye dönüştürürseniz boşluklar değişir ve imza tutmaz.
app.post("/hooks/pf", express.raw({ type: "application/json" }), (req, res) => {
  const raw = req.body.toString("utf8");
  const header = req.get("Webhook-Signature") ?? "";
  const m = /t=(\d+),v1=([0-9a-f]+)/.exec(header);
  if (!m) return res.sendStatus(400);

  const [, timestamp, signature] = m;
  // Tekrar saldırısına karşı: 5 dakikadan eski damgayı reddet.
  if (Math.abs(Date.now() / 1000 - Number(timestamp)) > 300) return res.sendStatus(400);

  const expected = crypto
    .createHmac("sha256", process.env.WEBHOOK_SECRET)
    .update(`${timestamp}.${raw}`, "utf8")
    .digest("hex");

  const ok =
    expected.length === signature.length &&
    crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signature));
  if (!ok) return res.sendStatus(401);

  const event = JSON.parse(raw);
  // 2xx dönmezseniz gönderim artan aralıklarla tekrar denenir.
  res.sendStatus(200);

  if (event.type === "order.completed") {
    // ... siparişi kendi sisteminizde tamamlandı olarak işaretleyin
  }
});

Retries

The first attempt happens as the event occurs. If the response is not 2xx, or the connection fails, delivery is retried after 1 minute, 5 minutes, 30 minutes, 2 hours and 6 hours. After 6 attempts the delivery is marked failed and shows up in the delivery log.

Event types

Subscribe to the types you care about, or receive all of them. A status change produces exactly one event, using the type that best matches the new status.

If you cannot host a webhook

The same events can be read with a cursor from GET /api/v3/events. Use it while developing locally, when you have no static IP, or from behind a firewall.

// Webhook kuramıyorsanız (yerelde geliştirme, sabit IP yok) aynı bilgiyi
// imleçle çekebilirsiniz. İmleci kendi tarafınızda saklayın.
let cursor = loadCursor(); // en son işlediğiniz olayın "cursor" değeri

const url = new URL("https://panelfollows.com/api/v3/events");
url.searchParams.set("limit", "100");
if (cursor) url.searchParams.set("starting_after", String(cursor));

const res = await fetch(url, { headers: { Authorization: "Bearer YOUR_API_KEY" } });
const { data, has_more } = await res.json();

for (const event of data) {
  handle(event);        // sizin işleyiciniz
  cursor = event.cursor; // imleci ilerlet
}
saveCursor(cursor);