---
schema_version: "1"
id: 7eabc713e7c90ce77c46c887d0f69a0bfdfb559fd2f99f18ff373d9bbf136abe
title: Shop Sessions (deprecated)
collection: developer
version: current
locale: en-us
portal_url: https://docs.salesforce.com/developer/current/en-us/commerce-cloud/b2c-commerce/references/generated-api-specs/ocapi-shop-sessions.md
canonical_url: https://developer.salesforce.com/docs/commerce/b2c-commerce/references/ocapi-shop-sessions
source_site: developer.salesforce.com
content_type: documentation
content_hash: 6cdec2cb8bde37075d3a80ff07349a6839ea3a374929b4917ca9fa083e73de75
products:
  - B2C Commerce
  - Salesforce APIs
---
Shop Sessions (deprecated)

# Shop Sessions (deprecated)

The Shop API endpoints enable developers to build full shopper-experience applications such as storefronts. They are designed for high-scale usage, and include a number of areas such as Baskets & Orders, Customers, Products and Pricing. Shop API endpoints are typically read-only APIs, with the exception of baskets and orders.

**Version:** 25.6

## Servers

*   `https://{host}/s/{siteId}/dw/shop/v25_6`

Protocols: https.

## Security

*   `customers_auth` (basic) User authentication either for a registered or a guest customer (selectable in request body). Access via Base64 encoded customer:password string as 'Authorization: Basic' header.
*   `oauth2_application` (oauth2) Authentication flow with client ID and password with account manager.
    *   OAuth flow application (tokenUrl: https://account.demandware.com:443/dwsso/oauth2/access\_token)
    *   Scope x-info: Scopes are NOT supported. This is just a dummy, because the 'scopes' field is required.
*   `client_id` (apiKey) Add client ID for application identification. Alternative as 'client\_id' query parameter.
    *   API key in header: x-dw-client-id

## Operations

### POST Exchange JWT

`POST /sessions`

Operation ID: `Exchange JWT`. Tags: sessions. Security: customers\_auth.

Exchanges a valid JWT into a new session, which is associated with the authenticated or anonymous customer. All _Set-Cookie_ headers for handling the session are applied on the response.

Only the JWT is used to create the new session. Any session IDs included in the request are ignored.

Once you create a session from a JWT, you can use it in parallel with stateless OCAPI calls that use the JWT. There is no need to call the bridging resources again.

If the customer is authenticated and has a storefront basket, that basket is transferred into the session and can be retrieved using BasketMgr.getCurrentBasket(), along with sensitive data such as addresses and payment information. The following examples show why this behavior is important to understand as it relates to guest customers:

Basket created after the session is created:

POST /customers/auth with type "guest"
POST /sessions
POST /baskets
Storefront request (controller with BasketMgr.getCurrentBasket())
-> Sensitive data is erased from the basket due to security considerations

Basket created before the session is created:

POST /customers/auth with type "guest"
POST /baskets
POST /sessions
Storefront request (controller with BasketMgr.getCurrentBasket())
-> Sensitive data is accessible because the basket is marked as secured for this session

#### Responses

*   **204**

## Schemas

### cause

*   `cause` (_cause_)
*   `message` (_string_)
*   `type` (_string_)

### fault

Document representing a fault message that is returned whenever the HTTP status code is greater than or equal to 400 (which indicates an error).

*   `arguments` (_object_)
    
    A map that provides fault arguments.
    
    Data can be used to provide error messages on the client side.
    
    Additional properties: `object`.
    
*   `cause` (_cause_)
*   `display_message_pattern` (_string_) The localized display message pattern, if the request parameter display\_locale was given
*   `message` (_string_) The message text of the java exception.
*   `stack_trace` (_string_)
*   `type` (_string_) The name of the java exception.