Sandbox and test keys

Your CI should not post to LinkedIn every time it runs, and mocking us means you are testing your mock. The sandbox validates a post like any other, stores it, returns the same shapes a real platform does and fires the same webhooks. It publishes nothing.

Every account starts with one, with the slug sandbox (sandbox_2 for the next one). Sandbox connections are free: they never count toward your plan's connections and never change what you are billed. Sandbox posts do not count toward the free daily post cap either.

curl -X POST https://api.yeetpost.com/api/v2/post/sandbox \
  -H "x-api-key: $YEETPOST_TEST_KEY" \
  -d 'does my pipeline work'

{
  "platform": "sandbox",
  "link": "https://app.yeetpost.com/sandbox/6f1b0c8a-1f3d-4d3e-9a2b-2f5a1c9e7d10"
}

An empty body is a 400, and text over 5000 characters is a 400 text_too_long. Scheduling works too, and the scheduled post goes through the same worker.

Create a test key in settings. Test keys start with yp_test_ instead of yp_secret_, and they reach sandbox connections and nothing else:

• GET /connections lists only your sandbox connections, and DELETE /connections/{connectionId} only reaches one.
• POST /post/{slug} and POST /posts refuse any other slug with invalid_connection and the message "test keys can only post to sandbox connections". On POST /posts that is per item, and for the whole request when no sandbox connection is named.
• GET /posts, GET /posts/{postId}, DELETE /posts/{postId} and POST /posts/{postId}/retry only see or touch sandbox posts.
• Test keys manage test webhooks, which receive only sandbox events.

The MCP server scopes a test key the same way.

A live key can post to a sandbox connection too, so you can smoke test with the real key without publishing anything. That is a live post: it goes to your live webhooks, and the deliveries are live.

Start the text with [fail] and the sandbox answers 422 platform_rejected with the message "sandbox failure requested", stores the post with that error and fires post.failed.

curl -X POST https://api.yeetpost.com/api/v2/post/sandbox \
  -H "x-api-key: $YEETPOST_TEST_KEY" \
  -d '[fail] does my error path work'

{
  "error": "platform_rejected",
  "message": "sandbox failure requested",
  "req_id": "req_43219876"
}

A webhook belongs to the mode of the key that created it, and it hears about posts made in that mode only. A test key creates test webhooks, and they receive sandbox events: your real receiver is never woken by a run of your test suite. A live key creates live webhooks, and it does not see, delete or read the deliveries of a test one (those ids answer 404), nor the other way round. So point your test webhook at your staging receiver, create it with your test key, and leave the live one alone.

Every delivery carries an x-yeetpost-mode header, which is test when the post behind it was made with a test key and live otherwise. Your receiver can key its behaviour off that header instead of guessing. See webhooks.