Repository navigation
Conversation
Adds a twittrapi provider next to the existing twitterapi.io one: API key in the X-API-KEY header (TWITTRAPI_API_KEY), base https://api.twittrapi.com, OpenAPI spec for docs lookup, and examples for user lookup, user tweets and search. The analytics template lists it as a data source, and the eject manifest, docs and credential guard list the new key.
![builder-io-integration[bot]](https://avatars.githubusercontent.com/in/353721?s=60&v=4){kind=small}
There was a problem hiding this comment.
Builder reviewed your changes and found 2 potential issues 🔴
Review Details
Code Review Summary
PR #7626 registers TwittrAPI as a second X/Twitter provider, adds its API-key auth, OpenAPI documentation and endpoint examples, exposes it through the analytics template, and updates eject metadata, docs, and the credential guard. The core provider definition is small and follows the existing registry pattern; the API base URL and X-API-KEY configuration and eject entries were confirmed consistent. Risk: Standard.
Key findings
- 🔴 HIGH — The Analytics walkthrough collects
TWITTRAPI_API_KEY, but that key is missing from Analytics’ runtime credential registry. Saving it is rejected and configured status cannot recognize it. - 🟡 MEDIUM — Analytics has no
twittrapitest-connection handler, so its Test connection action returns “Unknown source”. - 🟡 LOW — The pagination guidance says the response has a
cursorfield, while the upstream simple response usesnextCursorand related fields.
The provider API registration and auth wiring are otherwise consistent with the existing provider pattern. 🧪 Browser testing: Will run after this review (PR touches UI code).
| id: "twittrapi", | ||
| name: "TwittrAPI", | ||
| description: | ||
| "X/Twitter tweets, profiles, followers and search through the TwittrAPI REST API, no X developer account needed", | ||
| category: "communication", | ||
| icon: IconBrandX, | ||
| envKeys: ["TWITTRAPI_API_KEY"], |
There was a problem hiding this comment.
🔴 TwittrAPI credential is rejected by Analytics credential storage
The walkthrough collects TWITTRAPI_API_KEY, but Analytics only accepts keys registered in server/lib/credential-keys.ts; its credential-save action filters submissions against that registry and rejects an unrecognized key. Register the key (and provider status metadata as needed) so users can save it and see the source as configured.
| ], | ||
| }, | ||
| { | ||
| id: "twittrapi", |
There was a problem hiding this comment.
🟡 TwittrAPI connection test always reports an unknown source
The Analytics Test connection action passes this source ID to the server handler, which has no twittrapi case and returns Unknown source by default. Add a TwittrAPI-specific connection check so users can verify the integration with a valid key.
There was a problem hiding this comment.
Builder reviewed your changes and found 1 potential issue 🟡
Review Details
Incremental Code Review Summary
The latest PR head updates TwittrAPI pagination guidance: it now names nextCursor, previousCursor, and hasNextPage, and explains how to request another page. The earlier report's incorrect cursor-field names are therefore fixed. This update is still a Standard-risk provider integration. The credential-save and Analytics Test connection findings from the prior review remain unchanged and unresolved; I did not repost them.
New finding
- 🟡 MEDIUM — The new guidance describes the simple response envelope as if cursor fields were generally present, but single-result endpoints such as user-by-username return no pagination fields. Scope the envelope to paginated endpoints and make clear that pagination fields apply when using
format=simple.
The provider registration and auth wiring otherwise remain consistent. 🧪 Browser testing: Skipped — the browser-test-planner agent is unavailable; this incremental change only updates provider guidance.
| "Read endpoints for tweets, users, followers, search, lists and communities. Add format=simple for flat camelCase JSON in a {data, nextCursor, previousCursor, hasNextPage} envelope.", | ||
| "While hasNextPage is true, pass nextCursor back as the cursor query parameter for the next page.", |
There was a problem hiding this comment.
🟡 Pagination envelope guidance overgeneralizes cursor fields
The guidance presents {data, nextCursor, previousCursor, hasNextPage} as the simple response envelope generally, but single-result endpoints such as /user/by/username/{username} return only {data}. Scope the cursor-envelope guidance to paginated endpoints and explicitly tie the cursor instructions to format=simple, so agents do not expect pagination fields on lookup responses or raw-format results.
|
Thanks for the integration and clear disclosure. I still see three follow-ups before this can move forward: (1) register |
|
Apologies @twittrapi that prior message was sent from a bot - for now I want to try to keep the provider list as curated as possible to reduce our maintenance load. Going to close this out for now but if people start asking for TwittrAPI happy to take a second look |
Disclosure: I work on TwittrAPI.
What
Adds TwittrAPI as a built-in provider API for X/Twitter data, next to the existing
twitterprovider (twitterapi.io), so agents and the analytics template can use either one.twittrapiinPROVIDER_API_IDSandPROVIDER_CONFIGS:api-key-headerauth withTWITTRAPI_API_KEYsent asX-API-KEY, basehttps://api.twittrapi.com, the OpenAPI spec inspecUrlsfor docs lookup, and examples for user lookup, user tweets and search (format=simplereturns flat camelCase JSON in a{data, nextCursor, previousCursor, hasNextPage}envelope).twittrapidata source with setup steps.provider-api-definitions.ts, integrations docs,docs/environment-variables.mdand the credential guard list the new key.@agent-native/corepatch.Testing
packages/core:vitest run src/package-lifecycle/eject-manifest-repo.spec.ts src/provider-api src/eject(14 files, 266 tests) pass after building the workspace packages.templates/analytics: the data-source status and MCP exclusion specs pass.node scripts/guard-no-env-credentials.mjsis clean,oxfmt --checkpasses on the changed files.Something I noticed while reading the code (not changed here)
The existing X / Twitter data source in
templates/analytics/app/lib/data-sources.tstells users to create an app in the X Developer Portal and paste its Bearer Token, buttemplates/analytics/server/handlers/twitter.tsand thetwitterprovider send that value asX-API-Keytoapi.twitterapi.io. An X bearer token won't authenticate there, so users who follow those steps get errors. The steps probably want to point at a twitterapi.io API key instead. Happy to send that as a separate PR if you'd like.Thanks for considering it. If you'd rather not ship a second Twitter provider, a pointer to the preferred route (custom provider registry, community template) would be great too.