Stack Exchange API write endpoint testing boundary without OAuth sandbox

Answer

You cannot call any write endpoint without a valid OAuth 2.0 access token that carries the appropriate write scope; the client key only raises the read quota and does not cross the write boundary.

What preview=true actually does

The preview=true flag validates the request payload (JSON shape, required fields, value types) and returns a normal success response, but it does **not** guarantee that no side effect occurs. On several endpoints the server still creates the comment, answer, or edit tied to the authorizing user; the flag merely suppresses some secondary processing (e.g., notification generation) in certain contexts. Relying on it as a dry‑run safety switch is therefore unsafe.

Available options for integration testing

1. Mock the HTTP layer – In unit/CI tests replace the network call with a stub that returns a fabricated 200 response (or the appropriate error codes). This validates request construction, header handling, and error‑path logic without touching the API.
2. Use an invalid or missing token – Sending a request with a bogus OAuth token yields a 401/403 response, letting you verify that your client correctly handles authentication failures. No content is created because the request is rejected before reaching the write path.
3. Leverage a throwaway account on a secondary Stack Exchange site – If you can create a disposable user (e.g., on a meta site or a newly registered account) you can obtain a real OAuth token, call the endpoint with preview=true to check payload shape, and then delete any created content via the API or the site UI. This exercises the full round‑trip while keeping public impact minimal.

Recommended CI/CD pattern when no throwaway account is available

• Validate the JSON payload against a published schema (or a hand‑crafted one) before building the request.
• In the test suite, mock the endpoint to return:
  • 200 with a sample response when a valid token is present.
  • 401/403 when the token is missing or malformed.
  • 400 with validation error messages when the payload fails schema checks.
• Optionally add a test that sends a request with preview=true and an invalid token to confirm you receive 401/403 and that no network side effect occurs (you can verify by checking that the mock was not called with a successful token).

Missing diagnostic detail

If you **do** have access to a throwaway Stack Exchange account where you can safely create and later delete content, the recommendation shifts to using that account with a real OAuth token (still preferring preview=true for shape validation). Please confirm whether such an account is available for your test environment.