Clarify rollout/auth for documented GET /2/usage/credits: empty 404 on Pay Per Use

[OddsLogicZach]

Documentation versus live behavior

The GET /2/usage/credits documentation was added in #329 on August 24. The live OpenAPI, version 2.168, allows BearerToken or OAuth2UserToken with no operation-specific parameters. Our Pay Per Use project also lists this endpoint in its Console rate-limit catalog: 30 requests/15min per app or user.

The documented request consistently returns HTTP 404 with a zero-byte body. Is an endpoint rollout prerequisite, account entitlement, or required request detail missing from the documentation? If the request is correct, please route this to API engineering for a transaction trace.

Reproduction and controls

App: OddsLogicInjuryTool, 33357811, active. Project: 2092431245758140418, Pay Per Use.

• Valid app Bearer Token → /2/usage/tweets: 200, correct project.
• Deliberately invalid token → /2/usage/tweets: 401, structured Unauthorized JSON.
• Valid, invalid, or absent token → /2/usage/credits: identical empty 404, no JSON content type or endpoint rate-limit headers.
• Unauthenticated /2/account: normal structured 401.
• A deliberately nonexistent v2 path produces the same response class as credits.
• Reproduced using Node HTTPS, native fetch, and curl; HTTP/1.1 and actual HTTP/2; api.x.com and api.twitter.com; both DNS-advertised IPv4 addresses with TLS/SNI validation.
• Cache-bypass query plus no-cache headers still yields 404, CF-Cache-Status DYNAMIC.
• The Console successfully reads the funded balance through its separate internal Console endpoint. We are not treating that private endpoint as a supported backend substitute.

Trace references

All times UTC, September 8, 2026:

Case	UTC	x-transaction-id
Valid app Bearer, credits 404	18:29:29.019	586153a2a517f169
Same, second DNS address, 404	18:29:29.068	561c073908cf82e2
Unauthenticated /2/account, 401	18:51:13.396	ec4c65fb713280f5
Unauthenticated credits, 404	18:51:13.468	55be6619ed8c4c55
Valid Bearer, cache-bypass credits, 404	18:52:05.791	ec6585bfb58351d8

Successful /2/usage/tweets control: 22f860962b0e0f41, approximately 18:24:39 UTC.

Requested clarification

1. Is this endpoint currently deployed for Pay Per Use app-only Bearer authentication?
2. Is an additional supported scope, header, account mapping, or enrollment step required?
3. If not, please trace the empty 404 and confirm the actual correction or incident reference.

The response suggests routing or endpoint-access handling, but we cannot determine the internal cause externally. The unmerged announcement #330 is release-history context, not proof the service is undeployed.

An earlier developer-forum report remains pending moderation. No duplicate forum topic has been created. No credentials, cookies, or Authorization values are included here.

[OddsLogicZach]

Additional controlled OAuth comparison (2026-09-08 UTC):

We configured the same existing app as Native/Public with a local PKCE callback, retaining read-only permissions, and obtained a short-lived OAuth 2.0 user token with exactly developer.read (code exchange 200; transaction 1724fdb6783269de, 18:58:14.924). No offline/write scopes.

• Original app Bearer still returns /2/usage/tweets 200: df940ea5b1467c8b, 18:57:12.706.
• Original app Bearer credits remains empty 404 after setup: a5c0b6dfd7ed9287, 18:57:12.762.
• User OAuth credits also returns empty 404: 12a466cfc5fe71e7, 18:58:15.081.
• Important caveat: user OAuth /2/account returned 403 (463-byte JSON problem), transaction 81cde9e7f1452df6, 18:58:14.991. The diagnostic omitted that error body, so we do NOT claim a successful user-context developer-account control or know its denial reason.

Separate cleanup problem: revoking the temporary token returned 400. The normal X Connected Apps UI also fails to revoke this newly created developer.read grant: its POST /i/api/2/oauth2/revoke_token_hash returns 400 with {"error":"invalid_client","error_description":"Value passed for the client id was invalid."}. The grant remains listed. We are not asserting this is the cause of credits 404, but it may help investigate client/account mapping. The original app Bearer was not rotated or revoked.

Please trace the credits and account-denial transactions and clarify any required supported account enrollment/client configuration. OAuth setup alone has not corrected the public credits call.

[OddsLogicZach]

Fresh-app and independent-request-path control completed:

We created OLCreditsDiag20260908 (app 33414236) with a newly generated Bearer Token, attached to the same Pay Per Use project 2092431245758140418 in Development. The original app and token were preserved. Using the official docs.x.com Try it playground with BearerToken authentication:

Upstream X request	UTC Sep 8	Status	x-transaction-id	cf-ray
/2/usage/credits	19:58:11	404, zero-byte body	8828add3d599000b	a38086c72887e5e5-IAD
/2/usage/tweets?days=7	19:58:37	200, expected project ID	eef96ff75c5eec33	a380876bab9f617a-IAD

These are the actual upstream statuses returned by the playground, not its outer proxy status or documentation examples. Credits reported 3 ms response time and CF-Cache-Status DYNAMIC.

This reproduces the failure with a fresh app/key and a request path outside our local implementation, reaching IAD rather than the earlier direct Mac tests at LAX. It does not isolate a new developer account/project: both apps share the existing project. The Console currently offers only Ads API as a self-service new-project product, not a second Pay Per Use project.

Please help distinguish shared Pay Per Use project/account mapping or entitlement from availability of the public credits route. No tokens or session credentials are included.