feat(api): add clerk api --fapi for the public Frontend API#345
feat(api): add clerk api --fapi for the public Frontend API#345rafa-thayto wants to merge 3 commits into
clerk api --fapi for the public Frontend API#345Conversation
🦋 Changeset detectedLatest commit: e1b5db3 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Warning Review limit reached
More reviews will be available in 55 minutes and 8 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
wyattjoh
left a comment
wyattjoh
left a comment
There was a problem hiding this comment.
Clean, well-scoped addition that mirrors the existing BAPI/PLAPI passthrough patterns. A few follow-ups around dry-run semantics, a duplicated version constant, and silently-ignored flags.
clerk api spoke only BAPI and PLAPI, so verifying a config change against the instance's public FAPI /v1/environment (what clerk-js consumes) meant dropping to curl and decoding the FAPI domain out of the publishable key by hand. Add --fapi: resolve the FAPI host from the instance's publishable key (via --app/--instance or the linked project) and do an unauthenticated passthrough, reusing the existing lib/fapi.ts client. --fapi and --platform are mutually exclusive. Closes #332
- Move dry-run check before resolveFapiHost so --fapi --dry-run avoids the Platform API round-trip; shows <fapi-host> placeholder instead - Import CLERK_JS_API_VERSION from lib/fapi.ts instead of redeclaring it - Warn when --secret-key is provided with --fapi (key is ignored) - Add tests: --fapi no-app NOT_LINKED error, /environment and /v1/environment path normalization, --secret-key warning, --dry-run no network call
rafa-thayto
force-pushed
the
feat/api-fapi-passthrough
branch
from
8f9d521 to
64f6f75
Compare
There was a problem hiding this comment.
I think we should just be clearer that this only hits public endpoints.
Because it is possible to use the command line to hit FAPI with curl, and use auth, you just need to use a cookie jar. This is how I do it in my local skill for testing:
FAPI=""
jar=$(mktemp)
# 1. Create a dev browser; capture its token.
tok=$(curl -s -c "$jar" -X POST "$FAPI/v1/dev_browser" -H "Origin: $FAPI" | jq -r '.token')
# 2. Inspect what the instance has enabled (strategies, factors).
curl -s -b "$jar" -c "$jar" "$FAPI/v1/environment?__clerk_db_jwt=$tok" -H "Origin: $FAPI" \
| jq '.auth_config | {first_factors, identification_strategies, password}'
# 3. The client state (sessions, sign_in, sign_up).
curl -s -b "$jar" -c "$jar" "$FAPI/v1/client?__clerk_db_jwt=$tok" -H "Origin: $FAPI" \
| jq '.response | {sessions: (.sessions|length)}'- Refactor fallback branch of resolveInstance to use resolveFetchedApplicationInstance instead of hand-rolling app.instances.find (addresses wyattjoh comment 3) - Bump CLERK_JS_API_VERSION from "5" to "6" to match current clerk-js major (addresses dmoerner comment 6) - Clarify --fapi help text: "unauthenticated endpoints only" instead of "no auth" to avoid implying it skips auth on authenticated endpoints (addresses dmoerner comment 7)
3 participants
Summary
clerk apispoke only BAPI (default) and PLAPI (--platform). After a config change, the natural way to verify it took effect is the instance's public FAPI/v1/environmentpayload (what clerk-js actually consumes) — but that meant dropping tocurlplus decoding the FAPI domain out of the publishable key by hand.This adds
--fapi:--app/--instanceor the linked project through the Platform API), reusing the existinglib/fapi.tsclient anddecodePublishableKey./v1-normalized like the other modes, so both/environmentand/v1/environmentwork.--fapiand--platformare mutually exclusive.Implementation reuses the request-target resolution:
api()now builds a{ baseUrl, runRequest }pair, which also de-duplicates the BAPI/PLAPI branches. The local error handler was broadened fromBapiErrortoApiErrorso FAPI error bodies still print to stdout for piping.Test plan
src/commands/api/index.test.ts: host resolution + no auth header;--fapi/--platformconflict; FAPI error body printed to stdout with exit 1Closes #332