Shopware 6.7 brings meaningful refinements to its storefront and administration REST APIs, including tighter scope enforcement, normalized error structures, stricter context token requirements, and optimized pagination handling. For developers building integrations, mobile backends, or headless commerce pipelines, validating these endpoints reliably is non-negotiable. While specialized testing tools exist, Postman remains the most accessible and flexible option for rapid iteration, debugging, and CI-ready validation. This guide walks you through building a production-grade Postman workflow tailored specifically to Shopware 6.7+ APIs, emphasizing authentication flows, dynamic variable management, collection organization, and version-aware best practices.

Prerequisites

Before configuring your workspace, ensure you have:

  • A running Shopware 6.7 (or later) installation with API routes accessible
  • Postman installed (latest stable build recommended for modern script execution)
  • Valid API client credentials from your Shopware Administration (API → Credentials)
  • Basic familiarity with REST principles and HTTP status codes

Configuring Base URLs & Environment Variables

Hardcoding URLs across requests quickly becomes unmanageable. Start by creating a new Postman environment named Shopware 6.7. Define the following keys:

| Variable | Value Example | Purpose | |----------|---------------|---------| | base_url | https://your-domain.com | Root storefront address | | api_path | /store-api | API prefix used by Shopware | | access_token | (blank) | Populated dynamically during auth | | context_token | (blank) | Session identifier for stateful routes |

Every endpoint URL should reference these variables: ${base_url}${api_path}/your/endpoint. Switching between development, staging, or production becomes a single dropdown click.

Authentication Flow in Shopware 6.7+

Shopware 6.7 enforces stricter token lifecycle management. For server-to-server or backend integration testing, the OAuth2 client credentials flow is the standard. Create a request named 01-Get Access Token with:

  • Method: POST
  • URL: ${base_url}${api_path}/oauth/token
  • Body (x-www-form-urlencoded):
    • grant_type: client_credentials
    • client_id: Your API client identifier
    • client_secret: Your corresponding secret
    • scope: (leave empty for default storefront scope)

Upon successful execution, the response contains access_token and expires_in. Extract the token automatically by adding this script to the request's Tests tab:

if (pm.response.code === 200) {
    const json = pm.response.json();
    pm.environment.set("access_token", json.access_token);
    console.log("Access token updated in environment");
}

Stateful storefront routes (cart, checkout, customer addresses) additionally require a valid context token. Obtain one via GET ${base_url}${api_path}/context and store the returned sw-context-token in your environment for subsequent requests.

Crafting Requests Across Endpoint Types

Shopware 6.7 organizes all storefront routes under /store-api/. Authentication is handled through headers rather than query strings. For most GET and POST endpoints, attach:

  • Key: sw-access-key
  • Value: ${access_token}

Example: Product Query with Pagination

GET ${base_url}${api-api-path}/product?page=1&limit=15
Headers: sw-access-key -> ${access_token}

Example: Cart Modification (POST)

Stateful routes often require a structured JSON body rather than query parameters:

{
  "lines": [
    {
      "id": "product-id-here",
      "quantity": 2,
      "price": [{"value": 100.00, "currencyId": "b7d2554bccc948dd8fabc8a53c493aa4"}]
    }
  ]
}

Set the Content-Type: application/json header and include both sw-access-key and sw-context-token headers. Shopware 6.7 strictly validates payload schemas, so mismatched fields will trigger structured error responses rather than silent failures.

Organizing Collections & Automating Validation

Group your requests into folders that mirror Shopware’s routing structure: Auth, Products, Cart, Checkout, Customers. This improves readability and enables targeted runner execution.

Leverage Postman’s built-in test assertions to validate responses programmatically. Click the Tests tab on any request and insert:

pm.test("Request succeeds with 200 status", () => {
    pm.response.to.have.status(200);
});

pm.test("Response contains expected data structure", () => {
    const body = pm.response.json();
    if (body.data) {
        pm.expect(Array.isArray(body.data)).to.be.true;
        if (body.data.length > 0) {
            pm.expect(body.data[0].id).to.exist.and.to.be.a("string");
        }
    }
});

pm.test("Errors array matches Shopware schema", () => {
    const body = pm.response.json();
    if (body.errors) {
        pm.expect(Array.isArray(body.errors)).to.be.true;
        body.errors.forEach(err => {
            pm.expect(err.detail).to.exist;
            pm.expect(err.status).to.exist;
        });
    }
});

Run the entire collection via the Collection Runner, selecting your Shopware 6.7 environment. This automates schema validation, catches broken routes instantly, and serves as a regression baseline for future updates.

Shopware 6.7 Specific Considerations

Several architectural shifts in 6.7 directly impact how you design your Postman workflows:

  • Context Token Enforcement: Cart, checkout, and customer profile endpoints now strictly require a valid sw-context-token alongside the access key. Omitting it triggers 401 or context-resolution failures.
  • Pagination Optimization: Use the includes parameter to fetch only related entities (e.g., media, categories). This reduces payload size and prevents N+1 query penalties in custom integrations.
  • Error Normalization: Shopware 6.7 returns consistent error payloads with title, detail, status, and source fields. Assert these keys rather than parsing raw exception traces.
  • Rate Limit Headers: Responses include X-RateLimit-Remaining and Retry-After. Store these in environment variables to simulate throttling behavior during load testing.
  • CSRF Defaults: Local development may block preflight requests. Temporarily disable CSRF validation via configuration or use identical-origin tokens during UI-adjacent testing.

Best Practices & Troubleshooting

  • Always request the minimum required scope to avoid privilege escalation risks in production.
  • Use Postman’s Mock Server to simulate Shopware responses when your backend is offline or undergoing maintenance.
  • Validate negative flows: intentionally submit malformed payloads or expired tokens to confirm error handling matches 6.7 standards.
  • If you receive 401 Unauthorized, verify client secrets haven’t been regenerated, scopes align with the target route, and CORS isn’t intercepting preflight requests in local environments.
  • Export collections as .json files and store them in version control. Sync with Postman CLI (pm-collection-cli) for CI/CD pipeline integration.

Conclusion

Testing Shopware 6.7+ API endpoints with Postman becomes highly predictable when you combine dynamic environment variables, automated token acquisition, and modular collection routing. By aligning your workflow with 6.7’s tightened authentication, context enforcement, and normalized error schemas, you’ll catch integration defects earlier and maintain reliable storefront or headless syncs. Start with authentication validation, expand through core resource routes, and progressively add assertions that mirror your production logic. With a disciplined Postman setup, your Shopware integrations will remain stable across framework updates and deployment cycles. Happy testing!