-
Notifications
You must be signed in to change notification settings - Fork 755
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to inspect Stripe's requests #2198
Comments
@andrecasal We don't offer such a deep introspection today. The closest we have is to use the
This won't log our raw HTTP headers though or the raw body (since that could contain sensitive information). I see you already found your own workaround to inspect the requests though which is neat! I don't think we'd add deeper inspection to stripe-node or other SDKs today but that's partly because it was never asked before. Can you clarify what you were really trying to do on your end? Is this more for curiosity around how the internals of the SDK work as a one-off or is this something you need for a certain reason? |
Hey @remi-stripe, thanks for the feedback! Unfortunately, the
I'm quite surprised by this. I'd expect many devs to want to swap out Stripe's lib for a native fetch request, for how much more clear it is.
I'm building a tech stack over at launchfast.pro and one of its goals is to teach modern web dev and best practices. With all due respect for all the work put into libraries like Stripe's NodeJS library, they are great for quickly building stuff, but they do push us away from the platform. One of the features my product (LaunchFast) provides is Offline Development. For that, we're using MSW: import { HttpResponse, http, type HttpHandler } from 'msw'
import { requireHeader } from './utils.ts'
const { json } = HttpResponse
export const handlers: Array<HttpHandler> = [
http.post(
`https://api.stripe.com/v1/billing_portal/configurations`,
async ({ request }) => {
requireHeader(request.headers, 'Authorization')
return json({
// fake response
})
},
),
] To provide Mocking for Offline Development, we need to be able to answer all these questions:
Stripe's NodeJS Library doesn't allow us to answer any of them. Hence the switch to a native fetch request: const body = {
customer: customerId,
line_items: [{ price: priceId, quantity: 1 }],
mode: 'subscription',
payment_method_types: ['card'],
success_url: `${HOST_URL}/checkout`,
cancel_url: `${HOST_URL}/plans`,
...params,
}
const response = await fetch('https://api.stripe.com/v1/checkout/sessions', {
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded',
Authorization: `Bearer ${process.env.STRIPE_SECRET_KEY}`,
},
body: objectToQueryString(body),
}) |
Thanks for providing extra details! I get some of your points but overall it looks like your needs are more around teaching and not around really using our SDKs. We do abstract a lot of the complexity for developers because they don't need to know whether we use JSON or form-encoded in our API or how we handle authentication or HTTP headers. If you want to inspect the request, you can use stripe-mock which is a tool we built a few years ago to help mock our API and quickly run tests https://github.com/stripe/stripe-mock Your switch to a raw fetch is reasonable but it means rebuilding a ton of complex logic around error handling, idempotent retries, network error and losing valuable insights into various more advanced encoding logic for example. You also seem to use a "query string" pattern which works but is not something we encourage. I do see your specific need but I thing that my original position stands here. I don't remember this being asked before, except in rare cases where someone tried to debug something actively broken such as not passing the right parameters or a dependency mis-behaving (which we then replaced). I don't think that adding raw dumping of API requests and what happens under the hood is something that we'd add in the near future for that reason. |
Stripe-mock looks great, thanks for putting that on my radar 🙌
I'm confused. If I send JSON instead, I get this response: Error: Stripe API error: 400 - {
"error": {
"message": "Invalid request (check that your POST content type is application/x-www-form-urlencoded). If you have any questions, we can help at https://support.stripe.com/.",
"type": "invalid_request_error"
}
}
Please correct me if I'm wrong 🙏
if (!response.ok) {
const errorDetails = await response.text()
throw new Error(`Stripe API error: ${response.status} - ${errorDetails}`)
}
I don't know what you mean by "losing valuable insights into various more advanced encoding logic". As far as I can tell, the benefit of the Library is that it hides this complexity—which is also why I'd like to replace it—so we wouldn't have visibility on these insights. Thanks for this back-and-forth with me, I appreciate it 😊 |
We expect As for the second part, our SDKs will often do a lot more logic than simply returning whether the request succeeded. Our stripe-node SDK doesn't retry errors that were rate limited but many others do and we plan to also add this to stripe-node in the future. The SDK will add an idempotency key if you haven't generated one to handle network errors if you have retries enabled. I do get your points here though about wanting the SDK to be mostly a raw API request layer but that is not the goals we have for those on our end! |
Describe the bug
I'm seeking visibility on Stripe's requests.
In this piece of code:
One can't answer these questions:
Some of these questions have obvious answers, but I'd much rather have full visibility:
The common solution I see online is to set
logLevel: 'debug'
:But there is no such key on Stripe
16.12.0
or17.0.0
:P.S.: I realize this question may have been asked a million times before, but I couldn't find anything in old issues.
To Reproduce
N.A.
Expected behavior
N.A.
Code snippets
No response
OS
macOS
Node version
Node v20.11.0
Library version
stripe-node 17.0.0
API version
2024-09-30.acacia
Additional context
I've also tried Fiddler and Charles to intercept and log the HTTP requests with no luck.
The text was updated successfully, but these errors were encountered: