Repository navigation
Clarify rollout/auth for documented GET /2/usage/credits: empty 404 on Pay Per Use #395
Description
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
- Is this endpoint currently deployed for Pay Per Use app-only Bearer authentication?
- Is an additional supported scope, header, account mapping, or enrollment step required?
- 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.
Activity
OddsLogicZach commentedon Sep 8, 2026
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; transaction1724fdb6783269de, 18:58:14.924). No offline/write scopes./2/usage/tweets200:df940ea5b1467c8b, 18:57:12.706.a5c0b6dfd7ed9287, 18:57:12.762.12a466cfc5fe71e7, 18:58:15.081./2/accountreturned 403 (463-byte JSON problem), transaction81cde9e7f1452df6, 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.readgrant: itsPOST /i/api/2/oauth2/revoke_token_hashreturns 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 commentedon Sep 8, 2026
Fresh-app and independent-request-path control completed:
We created
OLCreditsDiag20260908(app33414236) with a newly generated Bearer Token, attached to the same Pay Per Use project2092431245758140418in Development. The original app and token were preserved. Using the official docs.x.com Try it playground with BearerToken authentication:/2/usage/credits8828add3d599000ba38086c72887e5e5-IAD/2/usage/tweets?days=7eef96ff75c5eec33a380876bab9f617a-IADThese 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.