docs.stripe.com

The Stripe API is organized around REST. Our API has predictable resource-oriented URLs, accepts form-encoded request bodies, returns JSON-encoded responses, and uses standard HTTP response codes, authentication, and verbs.

You can use the Stripe API in sandboxes without affecting your live data or interacting with banking networks. The API key that you use to authenticate the request determines whether the request runs in live mode or in a sandbox. Sandboxes support all v2 APIs. Test mode sandboxes support some v2 APIs.

The Stripe API doesn’t support bulk updates. You can work on only one object per request.

The Stripe API differs for every account as we release new versions and tailor functionality. Log in to see docs with your test key and data.

Was this section helpful?YesNo

Not a developer?

Use Stripe’s no-code options or apps from our partners to get started with Stripe and to do more with your Stripe account—no code required.

Base URL

https://api.stripe.com

Client Libraries

By default, the Stripe API Docs demonstrate using curl to interact with the API over HTTP. Select one of our official client libraries to see examples in code.

The Stripe API uses API keys to authenticate requests. You can view and manage your API keys in the Stripe Dashboard.

Test mode secret keys start with sk_ test_ and have unrestricted access to their sandboxes. In live mode, you configure a restricted API key (starts with rk_ live_ ) with specific API permissions. Using a restricted API key with only a subset of API permissions limits the damage a bad actor could cause if they obtained the key. In both test mode and live mode, you can create as many restricted API keys as you need for different use cases or components of your application. We also create a live mode secret key (starts with sk_ live_ ) that grants access to all Stripe API resources. To protect your business, use restricted API keys instead.

Your API keys carry many privileges. Follow best practices to keep your keys safe. Don’t embed secret or restricted API keys in source code or client-side applications. Instead, use your server platform’s secrets vault to provide keys to your server-side applications. If your platform doesn’t offer a secrets vault, set your keys in environment variables.

Make all API requests over HTTPS. Calls made over plain HTTP fail. API requests without authentication also fail.

Was this section helpful?YesNo

Authenticated Request

curl https://api.stripe.com/v1/charges \
  -u sk_test_BQokikJOvBiI2HlWgH4olfQ2sk_test_BQokikJOvBiI2HlWgH4olfQ2:
# The colon prevents curl from asking for a password.

Your API Key

A sample test API key is included in all the examples here, so you can test any example right away. Do not submit any personally identifiable information in requests made with this key.

To test requests using your account, replace the sample API key with your actual API key or sign in.

Stripe uses conventional HTTP response codes to indicate the success or failure of an API request. In general:

  • Codes in the 2xx range indicate success.
  • Codes in the 4xx range indicate an error that failed given the information provided. For example, an omitted required parameter, a failed charge, or a declined card.
  • Codes in the 5xx range indicate an error with the Stripe servers (these are rare).

Was this section helpful?YesNo

Attributes

  • codenullable string

    For some errors that could be handled programmatically, a short string indicating the error code reported.

  • decline_ codenullable string

  • messagenullable string

    A human-readable message providing more details about the error. For card errors, these messages can be shown to your users.

  • paramnullable string

    If the error is parameter-specific, the parameter related to the error. For example, you can use this to display a message near the correct form field.

  • payment_ intentnullable object

    The PaymentIntent object for errors returned on a request involving a PaymentIntent.

  • typeenum

    The type of error returned. One of api_ error, card_ error, idempotency_ error, or invalid_ request_ error

    Possible enum values

    api_ error

    card_ error

    idempotency_ error

    invalid_ request_ error

More

  • advice_ codenullable string

  • chargenullable string

  • doc_ urlnullable string

  • network_ advice_ codenullable string

  • network_ decline_ codenullable string

  • payment_ methodnullable object

  • payment_ method_ typenullable string

  • request_ log_ urlnullable string

  • setup_ intentnullable object

  • sourcenullable object

HTTP Status Code Summary

200OKEverything worked as expected.
400Bad RequestThe request was unacceptable, often due to missing a required parameter.
401UnauthorizedNo valid API key provided.
402Request FailedThe parameters were valid but the request failed.
403ForbiddenThe API key doesn’t have permissions to perform the request.
404Not FoundThe requested resource doesn’t exist.
409ConflictThe request conflicts with another request (perhaps due to using the same idempotent key).
424External Dependency FailedThe request couldn’t be completed due to a failure in a dependency external to Stripe.
429Too Many RequestsToo many requests hit the API too quickly. We recommend an exponential backoff of your requests.
500, 502, 503, 504Server ErrorsSomething went wrong on Stripe’s end. (These are rare.)

Error Types

api_ errorAPI errors cover any other type of problem (e.g., a temporary problem with Stripe’s servers), and are extremely uncommon.
card_ errorCard errors are the most common type of error you should expect to handle. They result when the user enters a card that can’t be charged for some reason.
idempotency_ errorIdempotency errors occur when an Idempotency-Key is re-used on a request that does not match the first request’s API endpoint and parameters.
invalid_ request_ errorInvalid request errors arise when your request has invalid parameters.

Read the original on docs.stripe.com ↗