Reusing Authentication Tokens Across Karate Scenarios with callSingle

Quick answer: reuse a login token with callSingle

If you need the same JWT (or any token) for many scenarios, define a login routine once and let Karate cache its result per thread with callSingle. This avoids sending the login request repeatedly while still keeping each parallel thread isolated.

How callSingle works – worked example

First create a feature that performs the login and returns the token. Save it as src/test/resources/auth.feature:

Feature: obtain auth token

  @ignore
  Scenario:
    Given url 'https://api.example.com/login'
    And request { username: '#(username)', password: '#(password)' }
    When method post
    Then status 200
    And def token = karate.response.token
    And print 'login obtained token: ' + token
    And return token

The @ignore tag prevents this scenario from being run as a normal test; it is only invoked via callSingle.

Next, in any test feature where you need the token, call the login feature once per thread and reuse the value:

Feature: API tests using cached token

  Background:
    * def token = callSingle read('classpath:auth.feature')
    * configure headers = { Authorization: 'Bearer #' + token }

  Scenario: get user profile
    Given path 'users', 'me'
    When method get
    Then status 200

  Scenario: update user setting
    Given path 'settings'
    And request { theme: 'dark' }
    When method put
    Then status 200

To run the tests, execute from the project root:

mvn test

You need JDK 11+ and Maven installed; no special OS permissions are required. Each parallel thread (configured via Karate’s parallel runner) will execute the login feature once, cache the returned token, and reuse it for its own scenarios.

You can verify the caching behavior by adding a log statement inside auth.feature (as shown) and observing that the login request appears only once per thread in the console output.

Limits and common mistakes

• Stale tokens – If the authentication endpoint uses a nonce, timestamp, or any value that changes per request, the cached token may become invalid after a short time, leading to 401 responses. In such cases avoid callSingle and call the login feature per scenario or refresh the token when needed.
• No automatic reset – callSingle keeps the cached value for the lifetime of the thread. If you test a logout flow that invalidates the token on the server, subsequent scenarios will still send the old cached token unless you explicitly call karate.reset() or start a new thread.
• Thread‑scope confusion – The cache is per thread, not global. If you run tests sequentially (single thread) you see one login for the whole run; with parallel execution you see one login per parallel worker. Do not assume the token is shared across threads.
• Missing header configuration – Remember to set the header after obtaining the token (as in the Background example). Forgetting this step results in requests being sent without authentication.

Practical way to check the result: add a temporary scenario that logs out via an endpoint that invalidates the token, then immediately try another request using the cached token. You should observe a 401, confirming that the token is stale and needs to be refreshed.