The ApiOptions define how the Vendure GraphQL APIs are exposed, as well as allowing the API layer to be extended with middleware.
string''Set the hostname of the server. If not set, the server will be available on localhost.
number3000Which port the Vendure server should listen on.
string'admin-api'The path to the admin GraphQL API.
string'shop-api'The path to the shop GraphQL API.
boolean | Record<string, any>falseEnables the GraphQL landing page served at the admin API path. Since Apollo Server 5 removed the GraphQL Playground, a truthy value now serves GraphiQL instead, and the object form is read as a boolean and otherwise ignored.
boolean | Record<string, any>falseEnables the GraphQL landing page served at the shop API path. Since Apollo Server 5 removed the GraphQL Playground, a truthy value now serves GraphiQL instead, and the object form is read as a boolean and otherwise ignored.
booleanfalseHas no effect. This option used to set the debug option of Apollo Server, which was
removed in Apollo Server 4.
booleanfalseHas no effect. This option used to set the debug option of Apollo Server, which was
removed in Apollo Server 4.
number100The maximum number of items that may be returned by a query which returns a PaginatedList response. In other words,
this is the upper limit of the take input option.
number1000The maximum number of items that may be returned by a query which returns a PaginatedList response. In other words,
this is the upper limit of the take input option.
Array<(context: ValidationContext) => any>[]Custom functions to use as additional validation rules when validating the schema for the admin GraphQL API ApolloServer validation rules.
Array<(context: ValidationContext) => any>[]Custom functions to use as additional validation rules when validating the schema for the shop GraphQL API ApolloServer validation rules.
string'vendure-token'The name of the property which contains the token of the active channel. This property can be included either in the request header or as a query string.
boolean | CorsOptions{ origin: true, credentials: true }Set the CORS handling for the server. See the express CORS docs.
The default value reflects the Origin header of any caller back as Access-Control-Allow-Origin
and sets Access-Control-Allow-Credentials: true. This means that any website can make cross-origin
requests to your Shop and Admin APIs. It is kept as the default because it is what makes a new
project work with any storefront during development.
For production, replace origin: true with the list of origins you actually serve. If you set
authOptions.cookieOptions.sameSite to 'none' (needed when the storefront is on a different site
to the server), an explicit origin list is the only thing preventing any website from acting as a
logged-in user. Vendure logs a warning at startup when it detects origin: true together with
credentials: true.
Example
boolean | CSRFPreventionOptionsv3.7.3falseEnables Apollo Server's built-in CSRF prevention on both the Shop API and the Admin API.
When enabled, Apollo rejects any request whose content-type is one that a browser lets an
HTML form or a simple fetch send without a preflight, namely
application/x-www-form-urlencoded, multipart/form-data and text/plain, unless the request
also carries an Apollo-Require-Preflight or x-apollo-operation-name header. Requests sent as
application/json, which is what all Vendure clients use for normal operations, are unaffected.
This blocks Login CSRF. Without it, a cross-site HTML form can POST
query=mutation { login(...) } to your API as a top-level navigation. That is not a
cross-origin request in the CORS sense, so apiOptions.cors does not stop it, and a
SameSite=Lax cookie does not stop it either, because a top-level navigation is allowed to
store a cookie with any SameSite value. The response sets a session cookie in the victim's
browser, and the victim continues shopping while logged in as the attacker.
Before enabling this, check that every client which uploads files to your API sends the
Apollo-Require-Preflight header, since multipart uploads use one of the blocked content
types. @vendure/admin-ui, @vendure/dashboard and @vendure/testing all send it. A custom
admin client built on apollo-upload-client does not send it unless you add it.
The same applies to GET requests, which carry no content type at all: a storefront that uses
GET for cacheable queries must send the Apollo-Require-Preflight header as well.
Passing an object instead of true replaces the list of headers which permit an operation,
which by default is x-apollo-operation-name and apollo-require-preflight. Use this when a
client cannot be changed to send either of those: name a header the client already sends, for
example { requestHeaders: ['x-my-client-header'] }, rather than turning the protection off.
The default is false to preserve the behaviour of existing clients. It is expected to change
to true in a future major release.
Example
Middleware[][]Custom Express or NestJS middleware for the server. More information can be found in the Middleware docs.
falseSet the trust proxy configuration for the server. See the express proxy docs.
ApolloServerPlugin[][]Custom ApolloServerPlugins which allow the extension of the Apollo Server, which is the underlying GraphQL server used by Vendure.
Apollo plugins can be used e.g. to perform custom data transformations on incoming operations or outgoing data.
booleanv1.5.0trueControls whether introspection of the GraphQL APIs is enabled. For production, it is recommended to disable introspection, since exposing your entire schema can allow an attacker to trivially learn all operations and much more easily find any potentially exploitable queries.
Note: when introspection is disabled, tooling which relies on it for things like autocompletion will not work.
Example
Architecture reviews, custom plugin work, migrations, ongoing support. Get a hand from the team that builds Vendure.
Talk to the team