How to Manage X Engagement Service Orders with TwexAPI

Engagement service orders should not be treated like a growth hack. They are operational requests that need approval, budget control, audit logs, and a clear understanding of the rules that apply to the campaign and platform.

This guide explains the TwexAPI endpoints involved in an engagement service order workflow: submitting an approved order with POST /twitter/action, saving the returned order_id, and checking delivery state with GET /twitter/action/order-status.

Before You Submit an Order

Build guardrails before you connect an order form to an API call.

Confirm that the target account or campaign is authorized.
Check that the activity is allowed by the relevant platform rules, customer contract, and local policy.
Require an internal approval ID, budget owner, and campaign reason.
Record the original target URL, requested service, quantity, requester, and timestamp.
Keep order submission separate from analytics reporting so paid activity is not mixed with organic performance.

If you cannot explain why an order is allowed and who approved it, do not automate it.

Submit an Approved Order

Send a POST request to:

https://api.twexapi.io/twitter/action

The request body uses three fields:

Field	Required	Notes
`service`	Yes	One of the service values supported by the endpoint, such as `likes`, `retweets`, `views`, `bookmarks`, or `followers`.
`link`	Yes	Full X or Twitter URL for the target tweet or profile.
`quantity`	Yes	Positive integer quantity. Validate against your own approval rules before submitting.

curl --request POST \
  --url https://api.twexapi.io/twitter/action \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '{
    "service": "views",
    "link": "https://x.com/username/status/1234567890",
    "quantity": 100
  }'

A successful response returns an order identifier:

{
  "code": 200,
  "msg": "success",
  "data": {
    "order_id": 12345
  }
}

Store the full request and response in your own order table. The order_id is the key you will use for status checks.

Check Order Status

Use the status endpoint to monitor progress:

GET https://api.twexapi.io/twitter/action/order-status?order_id=<order_id>

curl --request GET \
  --url 'https://api.twexapi.io/twitter/action/order-status?order_id=12345' \
  --header 'Authorization: Bearer <token>'

The status response can include fields such as order_id, start_count, fee, and status.

{
  "code": 200,
  "msg": "success",
  "data": {
    "order_id": 12345,
    "start_count": 0,
    "fee": 1,
    "status": "completed"
  }
}

Treat pending, in_progress, partial, completed, and failed as operational states. Do not assume delivery is complete until the status endpoint says so.

Python Order Client with Approval Metadata

The example below keeps the API call small and puts the operational safeguards in your application layer. It requires an approval ID and writes each submission to JSONL.

1import json
2from datetime import datetime, timezone
3from pathlib import Path
4
5import requests
6
7TOKEN = "<your_bearer_token>"
8ORDER_URL = "https://api.twexapi.io/twitter/action"
9STATUS_URL = "https://api.twexapi.io/twitter/action/order-status"
10ORDER_LOG = Path("engagement-service-orders.jsonl")
11
12headers = {
13    "Authorization": f"Bearer {TOKEN}",
14    "Content-Type": "application/json",
15}
16
17ALLOWED_SERVICES = {"likes", "retweets", "views", "bookmarks", "followers"}
18
19def submit_order(service, link, quantity, approval_id, requester, reason):
20    if service not in ALLOWED_SERVICES:
21        raise ValueError(f"Unsupported service: {service}")
22    if not approval_id:
23        raise ValueError("approval_id is required")
24    if quantity <= 0:
25        raise ValueError("quantity must be positive")
26
27    payload = {
28        "service": service,
29        "link": link,
30        "quantity": quantity,
31    }
32
33    response = requests.post(ORDER_URL, headers=headers, json=payload, timeout=30)
34    response.raise_for_status()
35    body = response.json()
36    order_id = (body.get("data") or {}).get("order_id")
37
38    log_row = {
39        "approval_id": approval_id,
40        "requester": requester,
41        "reason": reason,
42        "submitted_at": datetime.now(timezone.utc).isoformat(),
43        "request": payload,
44        "response": body,
45        "order_id": order_id,
46    }
47    with ORDER_LOG.open("a", encoding="utf-8") as f:
48        f.write(json.dumps(log_row, ensure_ascii=False) + "\n")
49
50    return order_id
51
52def check_status(order_id):
53    response = requests.get(
54        STATUS_URL,
55        headers={"Authorization": f"Bearer {TOKEN}"},
56        params={"order_id": order_id},
57        timeout=30,
58    )
59    response.raise_for_status()
60    return response.json()
61
62order_id = submit_order(
63    service="views",
64    link="https://x.com/username/status/1234567890",
65    quantity=100,
66    approval_id="APPROVAL-2025-001",
67    requester="campaign-ops@example.com",
68    reason="Approved campaign operations request",
69)
70
71print(check_status(order_id))

For production, store orders in a database rather than a local JSONL file, and keep access to this workflow limited to approved operators.

Operational Checks

Use a checklist before every order:

Check	Why it matters
Target URL is correct	Prevents sending activity to the wrong tweet or profile.
Campaign is approved	Creates accountability before money is spent.
Quantity matches approval	Prevents accidental over-ordering.
Service type is allowed	Keeps the workflow inside your policy boundaries.
Order ID is stored	Makes status checks and support requests possible.
Reporting is labeled	Keeps paid activity separate from organic analysis.

These checks make the workflow less surprising for marketing, finance, and support teams.

Status Tracking Pattern

A simple polling job can update order status until the order reaches a terminal state.

1import time
2
3TERMINAL_STATUSES = {"completed", "failed"}
4
5def wait_for_terminal_status(order_id, poll_seconds=60, max_checks=30):
6    for _ in range(max_checks):
7        body = check_status(order_id)
8        status = (body.get("data") or {}).get("status")
9        print(f"order={order_id} status={status}")
10
11        if status in TERMINAL_STATUSES:
12            return body
13
14        time.sleep(poll_seconds)
15
16    raise TimeoutError(f"Order {order_id} did not reach a terminal status")

Keep the polling interval reasonable. Status checks should help operations, not create unnecessary load.

Common Pitfalls

Submitting orders without an approval record.
Mixing paid and organic metrics in the same report without labels.
Retrying a failed submission without checking whether an order was created.
Sending activity to the wrong URL because the target was not normalized.
Treating partial as completed.
Giving broad API access to people who should only request campaigns.

Wrap-up

Use POST /twitter/action only as the final step in an approved workflow. Save the request, response, approval metadata, and order_id; then monitor status with GET /twitter/action/order-status.

The technical API call is simple. The important work is the control layer around it: validation, approvals, auditability, and clear reporting boundaries.