Make your first API request

Start by reading your posts. This request does not create, schedule, or publish anything.

You need a user-generated API key and the origin of the YouScaleIt website running the API endpoints.

Choose the website URL

The examples use the full production website URL. For local development, replace the origin:

• Production website: https://youscale.it (the updated endpoints must be deployed there).
• Local development example: https://local.exiiit.com:5173, when your local server is running with a trusted development certificate.

The paths in this reference already start with /api. Do not append /v1 or use the backend API host for these website endpoints. Earlier examples on the API Keys screen may show a different backend-oriented URL/header; use the website URL and header documented here for these routes.

Set YOUSCALEIT_API_KEY to the full key in your terminal environment or server’s secret storage. Never commit its value or paste it into support messages.

Read the first page of posts

curl "https://youscale.it/api/profile/posts?page=1&limit=20"   -H "x-youscaleit-api-key: $YOUSCALEIT_API_KEY"

cURL uses GET by default, so this read needs only the URL and API-key header. There is no request body. Avoid verbose request logging because it can expose the key.

An empty page returns:

{
	"success": true,
	"data": {
		"data": [],
		"total": 0,
		"page": 1,
		"limit": 20
	}
}

The posts are in data.data. Pagination information is in data.total, data.page, and data.limit. Increase the page while page × limit < total.

Add filters

Add &status=DRAFT to the URL to read drafts, or &platform=LINKEDIN to filter by stored LinkedIn content. Keep the URL quoted. URL-encode spaces and special characters in search text, for example search=product%20update. You can also search post content. Use the read endpoint reference for the exact accepted parameters and limits; unknown post-list query parameters are rejected.

Other reads

All use GET and the same website authentication header:

See API read endpoints for response fields and examples for each operation. REST inputs and response envelopes are not MCP tool calls.

Drafts, publishing, and scheduling

After verifying a read, follow REST drafts, publishing, and scheduling for the other 14 operations: composer-style draft creation/editing, X threads, saved destinations, auto-comment creation, publishing/status, scheduling, and reposts. Together with the five reads, these make 19 website API-key operations.

REST drafts use isPostUnified and named platform objects such as xPost; unified content requires no platform list. Do not copy the separate MCP draft payload into REST. Run write examples individually: they can create real publications or future schedules.

Check authentication and failures

These routes accept either a browser session or an API key. When both exist, the session takes priority. Use cURL without browser cookies to verify API-key access specifically; keep integration keys on your server, not in browser code.

Check the response’s success value. Add -i to a cURL command to see the HTTP status and headers; plain cURL does not report HTTP errors as command failures by default. Missing credentials produce HTTP 401. Other failures are deliberately generic: the new post and auto-comment routes can return HTTP 404 for an upstream authentication/access failure as well as a missing resource. A failed request is not an empty result. See the error reference and troubleshooting.

Read one small page and confirm that it belongs to the account or workspace you intended before building an automation.