How to Publish X Posts with TwexAPI

TwexAPI exposes POST https://api.twexapi.io/twitter/tweets/create for creating X posts and replies. Because this is a write endpoint, treat it differently from read-only search APIs: review the content first, store account credentials securely, and keep a record of every attempted publish.

This guide focuses on a controlled publishing workflow for approved content. It is not a pattern for unsolicited replies, low-quality mass posting, or deceptive automation.

Endpoint and Required Fields

Use POST /twitter/tweets/create when you want to publish with an account cookie or auth token.

Field	Type	Required	Notes
`tweet_content`	string	Yes	Text to publish. Validate length and policy before sending.
`cookie`	string	Yes	X authentication cookie or `auth_token`. Store it in a secret manager or environment variable.
`media_url`	string or null	No	URL of media to attach.
`reply_tweet_id`	string or null	No	Tweet ID to reply to.
`schedule`	string or null	No	ISO timestamp for scheduled publishing.
`community_name`	string or null	No	Community name or community ID.
`delegated_account_username`	string or null	No	Delegated account username when your setup uses delegation.
`proxy`	string or null	No	Network route used by your posting setup. Keep it managed and compliant.

TwexAPI also exposes POST /twitter/post-tweet-without-cookie, which uses a cookie pool instead of a cookie in the request body. Use that only if your operational model explicitly depends on a managed account pool. For most owned-account publishing workflows, the explicit-cookie endpoint is easier to audit.

Basic Request

curl --request POST \
  --url https://api.twexapi.io/twitter/tweets/create \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '{
    "tweet_content": "Product changelog: the CSV export now includes reply counts and quote counts.",
    "cookie": "<x_auth_cookie_or_auth_token>"
  }'

A successful response returns code, msg, and data. The data object can include tweet_id, user_id, and a response code.

{
  "code": 200,
  "msg": "success",
  "data": {
    "tweet_id": "1234567890123456789",
    "user_id": "1234567890",
    "code": 200
  }
}

Python Client

Keep credentials out of source code. This client reads the Bearer token and X cookie from environment variables, validates the post text, and returns the response payload.

1import os
2from typing import Any
3
4import requests
5
6API_URL = "https://api.twexapi.io/twitter/tweets/create"
7BEARER_TOKEN = os.environ["TWEXAPI_BEARER_TOKEN"]
8X_COOKIE = os.environ["TWEXAPI_X_COOKIE"]
9
10def validate_post_text(text: str) -> None:
11    if not text or not text.strip():
12        raise ValueError("tweet_content cannot be empty")
13    if len(text) > 280:
14        raise ValueError(f"tweet_content is too long: {len(text)} characters")
15
16def publish_post(
17    text: str,
18    *,
19    media_url: str | None = None,
20    reply_tweet_id: str | None = None,
21    schedule: str | None = None,
22    community_name: str | None = None,
23) -> dict[str, Any]:
24    validate_post_text(text)
25
26    payload: dict[str, Any] = {
27        "tweet_content": text,
28        "cookie": X_COOKIE,
29    }
30
31    if media_url:
32        payload["media_url"] = media_url
33    if reply_tweet_id:
34        payload["reply_tweet_id"] = reply_tweet_id
35    if schedule:
36        payload["schedule"] = schedule
37    if community_name:
38        payload["community_name"] = community_name
39
40    response = requests.post(
41        API_URL,
42        headers={
43            "Authorization": f"Bearer {BEARER_TOKEN}",
44            "Content-Type": "application/json",
45        },
46        json=payload,
47        timeout=30,
48    )
49    response.raise_for_status()
50    return response.json()
51
52if __name__ == "__main__":
53    result = publish_post(
54        "Product changelog: the CSV export now includes reply counts and quote counts."
55    )
56    print(result["data"]["tweet_id"])

Replies, Media, Scheduling, and Communities

The same endpoint supports several publishing modes. Keep each mode explicit so your logs show why a post was sent.

1# Reply to an existing post.
2reply_result = publish_post(
3    "Thanks for reporting this. We shipped a fix in the latest export job.",
4    reply_tweet_id="1234567890123456789",
5)
6
7# Attach media by URL.
8media_result = publish_post(
9    "Here is the updated reporting layout.",
10    media_url="https://example.com/reporting-layout.png",
11)
12
13# Schedule a future post with an ISO timestamp.
14scheduled_result = publish_post(
15    "Maintenance window starts in one hour.",
16    schedule="2026-07-01T12:00:00Z",
17)
18
19# Publish inside a community by name or ID.
20community_result = publish_post(
21    "Sharing the release notes for community feedback.",
22    community_name="1234567890123456789",
23)

For replies, confirm the target tweet before publishing. For scheduled posts, store the intended publish time in your own system as well as sending it to the API.

Approval-First Publishing

A safer publishing system has a draft state before the API call. At minimum, store:

draft_id
account_id
tweet_content
optional media_url, reply_tweet_id, schedule, and community_name
approved_by
approved_at
final tweet_id after publishing

1def publish_approved_draft(draft: dict[str, Any]) -> dict[str, Any]:
2    if draft.get("status") != "approved":
3        raise ValueError("Draft must be approved before publishing")
4
5    result = publish_post(
6        draft["tweet_content"],
7        media_url=draft.get("media_url"),
8        reply_tweet_id=draft.get("reply_tweet_id"),
9        schedule=draft.get("schedule"),
10        community_name=draft.get("community_name"),
11    )
12
13    return {
14        "draft_id": draft["draft_id"],
15        "tweet_id": result.get("data", {}).get("tweet_id"),
16        "user_id": result.get("data", {}).get("user_id"),
17        "api_code": result.get("code"),
18        "api_msg": result.get("msg"),
19    }

This keeps the API call small while your application handles content approval, retry policy, and audit history.

Common Pitfalls

Do not hardcode cookie values in scripts, logs, or repositories.
Do not publish automatically from unreviewed search results.
Validate text length before calling the endpoint.
Use reply_tweet_id only after confirming the target post is the one you intend to answer.
Store tweet_id from the response so retries do not create duplicate posts.
Keep a human approval path for campaigns, customer replies, and community posts.

Wrap-up

POST /twitter/tweets/create is the direct TwexAPI endpoint for publishing X posts and replies. The best implementation is not the fanciest automation loop. It is a simple, auditable flow: draft, approve, publish, store the response, and review failures.

That keeps programmatic publishing useful without turning it into uncontrolled posting.