> For the complete documentation index, see [llms.txt](https://docs.solutioo.de/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.solutioo.de/shopware/shopware6_en_us/configuration/authentication-methods-in-detail.md).

# Authentication Methods in Detail

The connector authenticates itself against the Shopware Admin API using **OAuth** and receives a **bearer token** that is used for all subsequent calls. There are two procedures, which you switch between using the **Shopware Integration Access** toggle.

**Comparison of the Procedures**

{% tabs %}
{% tab title="Integration access (recommended)" %}
***Integration Access***** toggle = enabled.**

* You store the **Access Key ID** and **Secret Access Key** from a Shopware integration.
* Technically: `grant_type = client_credentials`.
* Advantage: not tied to a personal user, ideal for automated processes.

**How to create an integration in Shopware:** Administration → Settings → System → Integrations → *Add integration*. Copy the *Access key ID* and *Secret access key*.
{% endtab %}

{% tab title="Password grant" %}
***Integration Access***** toggle = disabled.**

* You store the **user name** and **password** of a Shopware administrator.
* Technically: `grant_type = password`, `client_id = administration`.
* Advantage: quick to set up. Disadvantage: tied to one user and that user's password.
  {% endtab %}
  {% endtabs %}

{% hint style="success" %}
**Recommendation:** Use **integration access** for productive, automated operation. It is more stable and independent of user password changes.
{% endhint %}

**Fields in the Configuration**

| Field                  | With integration access | With password grant |
| ---------------------- | ----------------------- | ------------------- |
| Shopware User Name     | Access Key ID           | User name           |
| Shopware User Password | Secret Access Key       | Password            |
| Integration Access     | enabled                 | disabled            |

**Security**

* Credentials are stored **masked**.
* The token is retrieved again automatically when required.
* Grant the integration in Shopware only the **required permissions** (write access to the relevant areas).

{% hint style="warning" %}
If you change the password of the administration user, the password grant fails until you store the new password. Integration access is not affected by this.
{% endhint %}

### Frequently Asked Questions

#### Which endpoint and which grant type does the connector use to sign in?

Sign-in takes place at the `oauth/token` endpoint. With integration access, the connector uses `grant_type=client_credentials` with a client ID and client secret; with an admin user, it uses `grant_type=password` with `client_id=administration`, user name, and password. The bearer token that is returned is sent with all subsequent calls in the `Authorization: Bearer {token}` header and is renewed automatically when it expires.

#### What exactly does the "Test Connection" action check?

"Test Connection" internally calls the token sign-in (`GetToken`). If the token is retrieved successfully, the combination of Website URL, API Module Path, and credentials is correct. If it fails and the "Developer Log" is active, the connector logs the exact server response in the API Call Log.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.solutioo.de/shopware/shopware6_en_us/configuration/authentication-methods-in-detail.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.