Account Sessions

Endpoint

The account sessions endpoint accepts only POST requests. Even though this is a read operation that retrieves data without modifying anything, it uses POST because the endpoint accepts an optional JSON request body containing filter and pagination parameters. If you do not need any filters, you can send a POST request with an empty body or an empty JSON object, and the endpoint will return the first 20 sessions ordered by creation date (newest first) with no status filter applied. This means you will see active, closed, and expired sessions mixed together in chronological order.

Authentication

All requests to the BBRE API require authentication via an API key. You must include your API key in the HTTP headers of every request, including session listing queries. The API accepts the key through either the x-api-key header or the apikey header. Both header names are supported and functionally identical. If no API key is provided, the API returns a 401 error with the API_KEY_REQUIRED error code. If the provided key is invalid or belongs to a suspended or inactive account, the API returns a 403 error with the appropriate error code (INVALID_API_KEY, ACCOUNT_SUSPENDED, or ACCOUNT_INACTIVE).

The sessions endpoint identifies your account entirely through the API key and returns only sessions that belong to that account. There is no way to view sessions from other accounts, and the API key determines which account's sessions are returned. Make sure your API key is sent as an HTTP header and not as a query parameter, because the BBRE API does not support query parameter authentication.

Request Parameters

The account sessions endpoint accepts an optional JSON request body with filter and pagination parameters. All parameters are optional. If you send an empty body or omit the body entirely, the endpoint returns the first 20 sessions across all statuses, ordered by creation date (newest first). The status parameter lets you filter sessions by their current state, while limit and offset control pagination. These parameters work together: you can filter by status and paginate through the filtered results, or paginate through all sessions without any status filter.

The status filter is case-sensitive and must be one of the three accepted values exactly as shown. Sending an unrecognized status value will return an empty result set rather than an error. The limit and offset values must be non-negative integers. The pagination applies after the status filter, so if you filter by "active" and set limit to 10, you will get up to 10 active sessions regardless of how many closed or expired sessions exist.

Response Format

The sessions endpoint returns a JSON response containing an array of session objects and a pagination metadata object. On success, the response includes the standard BBRE success fields, the sessions array with detailed information about each session, and a pagination object that tells you the total number of matching sessions, the current limit, and the current offset. This pagination metadata is essential for building pagination controls in your application because it tells you whether there are more pages of results to fetch.

Success Response (200)

A successful sessions query returns the following structure. The sessions array contains session objects ordered by creation time (newest first). Each session object includes all the information you need to understand the session's configuration, current state, usage statistics, and lifecycle timestamps. The pagination object provides the total count of matching sessions (after applying any status filter), the limit that was used for this query, and the offset that was used.

{
  "success": true,
  "service": "MyDisct Solver BBRE",
  "sessions": [
    {
      "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "mode": "adaptive",
      "sensibility": "medium",
      "status": "active",
      "requestCount": 15,
      "totalCharged": 0.075,
      "expiresAt": "2024-06-15T11:30:00.000Z",
      "createdAt": "2024-06-15T10:30:00.000Z",
      "closedAt": null
    },
    {
      "id": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
      "mode": "passive",
      "sensibility": "low",
      "status": "closed",
      "requestCount": 42,
      "totalCharged": 0.210,
      "expiresAt": "2024-06-14T16:00:00.000Z",
      "createdAt": "2024-06-14T14:00:00.000Z",
      "closedAt": "2024-06-14T15:45:00.000Z"
    }
  ],
  "pagination": {
    "total": 42,
    "limit": 20,
    "offset": 0
  }
}

Sessions Array Fields

Each object in the sessions array represents a single session and contains the following fields. These fields provide a complete picture of the session's configuration, current state, and usage statistics.

Pagination Object

The pagination object provides metadata about the total result set and the current page position. Use these values to calculate whether there are more pages to fetch and to construct the offset for the next page request.

Error Response Examples

When the sessions query fails, the API returns an error response with the appropriate HTTP status code, error code, and a descriptive message. The most common error scenarios for this endpoint are authentication-related, since the endpoint parameters are all optional and the endpoint is lenient about unrecognized values.

401 - API Key Required

{
  "success": false,
  "service": "MyDisct Solver BBRE",
  "error": {
    "code": "API_KEY_REQUIRED",
    "message": "API key is required. Please provide your API key in the x-api-key or apikey header."
  }
}

403 - Invalid API Key

{
  "success": false,
  "service": "MyDisct Solver BBRE",
  "error": {
    "code": "INVALID_API_KEY",
    "message": "The provided API key is invalid or does not exist."
  }
}

403 - Account Suspended

{
  "success": false,
  "service": "MyDisct Solver BBRE",
  "error": {
    "code": "ACCOUNT_SUSPENDED",
    "message": "Your account has been suspended. Please contact support for more information."
  }
}

500 - Service Error

{
  "success": false,
  "service": "MyDisct Solver BBRE",
  "error": {
    "code": "SERVICE_ERROR",
    "message": "An internal server error occurred. Please try again later."
  }
}

Filtering Examples

The status parameter lets you narrow the session list to only sessions in a specific state. This is particularly useful when you need to find active sessions that are consuming your session quota, review closed sessions to understand past usage, or identify expired sessions that were never properly cleaned up. The following examples demonstrate each filter option with the expected request body and a representative response.

Filter by Active Sessions

Filtering by "active" status returns only sessions that are currently usable and accepting requests. This is the most common filter because it tells you exactly how many of your 10 session slots are occupied and which sessions are consuming them. Active sessions have a future expiresAt timestamp and a null value for closedAt.

{
  "status": "active"
}

Response when you have 3 active sessions:

{
  "success": true,
  "service": "MyDisct Solver BBRE",
  "sessions": [
    {
      "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "mode": "adaptive",
      "sensibility": "medium",
      "status": "active",
      "requestCount": 15,
      "totalCharged": 0.075,
      "expiresAt": "2024-06-15T11:30:00.000Z",
      "createdAt": "2024-06-15T10:30:00.000Z",
      "closedAt": null
    },
    {
      "id": "c3d4e5f6-a7b8-9012-cdef-123456789012",
      "mode": "passive",
      "sensibility": "low",
      "status": "active",
      "requestCount": 8,
      "totalCharged": 0.040,
      "expiresAt": "2024-06-15T12:00:00.000Z",
      "createdAt": "2024-06-15T10:00:00.000Z",
      "closedAt": null
    },
    {
      "id": "d4e5f6a7-b8c9-0123-defa-234567890123",
      "mode": "adaptive",
      "sensibility": "high",
      "status": "active",
      "requestCount": 3,
      "totalCharged": 0.045,
      "expiresAt": "2024-06-15T11:00:00.000Z",
      "createdAt": "2024-06-15T09:00:00.000Z",
      "closedAt": null
    }
  ],
  "pagination": {
    "total": 3,
    "limit": 20,
    "offset": 0
  }
}

Filter by Closed Sessions

Filtering by "closed" status returns sessions that were explicitly terminated using the POST /session/close endpoint. Closed sessions have a non-null closedAt timestamp that indicates exactly when the session was terminated. Reviewing closed sessions is useful for understanding your session usage patterns and verifying that your cleanup logic is working correctly.

{
  "status": "closed",
  "limit": 5
}

Filter by Expired Sessions

Filtering by "expired" status returns sessions that reached their timeout duration without being explicitly closed. Expired sessions indicate that your application created sessions but did not close them when they were no longer needed. A high number of expired sessions suggests that your session cleanup logic needs improvement. Expired sessions have an expiresAt timestamp in the past and typically have a null value for closedAt because they were never explicitly closed.

{
  "status": "expired",
  "limit": 10,
  "offset": 0
}

Pagination Through All Sessions

When you have more sessions than the page size, use the offset parameter to navigate through pages. The pagination.total field in the response tells you the total number of matching sessions, so you can calculate how many pages exist and whether there are more results to fetch. To get the next page, add the current limit to the current offset.

{
  "limit": 10,
  "offset": 20
}

This request skips the first 20 sessions and returns sessions 21 through 30. If the pagination.total is 42, you know there are 2 more pages after this one (sessions 31-40 and 41-42).

Session Management Patterns

The sessions endpoint is most valuable when combined with other session-related endpoints to implement automated session management. The following patterns demonstrate common approaches to session lifecycle management that you can adapt to your specific use case. These patterns help you stay within the 10 active session limit, clean up unused sessions, and monitor session utilization across your application.

Finding Active Sessions Before Creating New Ones

Before creating a new session, check how many active sessions you currently have. If you are at or near the 10-session limit, you need to close an existing session first. This pre-flight check prevents SESSION_LIMIT_REACHED errors and gives you the opportunity to reuse an existing session instead of creating a new one. Reusing sessions is more efficient because you avoid the session creation overhead and maintain the existing browser context, cookies, and profile data.

const API_BASE = "https://bbre-solver-api.mydisct.com";
const API_KEY = "YOUR_API_KEY";
const MAX_ACTIVE_SESSIONS = 10;

async function getActiveSessions() {
  const response = await fetch(API_BASE + "/account/sessions", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "x-api-key": API_KEY
    },
    body: JSON.stringify({ status: "active" })
  });

  const data = await response.json();
  return data.sessions;
}

async function createSessionSafely(options) {
  const activeSessions = await getActiveSessions();

  if (activeSessions.length >= MAX_ACTIVE_SESSIONS) {
    console.log("Session limit reached. Active sessions: " + activeSessions.length);
    console.log("Close an existing session before creating a new one.");
    return null;
  }

  console.log("Active sessions: " + activeSessions.length + "/" + MAX_ACTIVE_SESSIONS);

  const response = await fetch(API_BASE + "/session/create", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "x-api-key": API_KEY
    },
    body: JSON.stringify(options)
  });

  const data = await response.json();
  console.log("New session created: " + data.sessionId);
  return data.sessionId;
}

createSessionSafely({
  mode: "adaptive",
  sensibility: "medium"
});

Cleaning Up Stale Sessions

Over time, your account may accumulate active sessions that are no longer being used by your application. This can happen when your application crashes without closing its sessions, when you restart your application during development, or when a session is created for a one-time task and forgotten. The following pattern identifies active sessions that have not received any requests recently and closes them to free up session slots.

const API_BASE = "https://bbre-solver-api.mydisct.com";
const API_KEY = "YOUR_API_KEY";
const authHeaders = {
  "Content-Type": "application/json",
  "x-api-key": API_KEY
};

async function cleanupStaleSessions() {
  const response = await fetch(API_BASE + "/account/sessions", {
    method: "POST",
    headers: authHeaders,
    body: JSON.stringify({ status: "active" })
  });

  const data = await response.json();
  const activeSessions = data.sessions;
  let closedCount = 0;

  for (const session of activeSessions) {
    if (session.requestCount === 0) {
      console.log("Closing unused session: " + session.id);
      await closeSession(session.id);
      closedCount++;
    }
  }

  console.log("Cleanup complete. Closed " + closedCount + " stale sessions.");
  console.log("Remaining active sessions: " + (activeSessions.length - closedCount));
}

async function closeSession(sessionId) {
  const response = await fetch(API_BASE + "/session/close", {
    method: "POST",
    headers: authHeaders,
    body: JSON.stringify({ sessionId: sessionId })
  });
  return response.json();
}

cleanupStaleSessions();

Session Utilization Report

Build a utilization report that summarizes your session usage across all statuses. This pattern fetches sessions from each status category and calculates aggregate statistics like total requests, total charges, and average requests per session. This data helps you understand your session usage patterns and optimize your session management strategy.

const API_BASE = "https://bbre-solver-api.mydisct.com";
const API_KEY = "YOUR_API_KEY";
const authHeaders = {
  "Content-Type": "application/json",
  "x-api-key": API_KEY
};

async function getSessionsByStatus(status) {
  const response = await fetch(API_BASE + "/account/sessions", {
    method: "POST",
    headers: authHeaders,
    body: JSON.stringify({ status: status, limit: 100 })
  });
  const data = await response.json();
  return { sessions: data.sessions, total: data.pagination.total };
}

async function generateUtilizationReport() {
  const active = await getSessionsByStatus("active");
  const closed = await getSessionsByStatus("closed");
  const expired = await getSessionsByStatus("expired");

  console.log("=== Session Utilization Report ===");
  console.log("Active sessions: " + active.total);
  console.log("Closed sessions: " + closed.total);
  console.log("Expired sessions: " + expired.total);

  const allSessions = [
    ...active.sessions,
    ...closed.sessions,
    ...expired.sessions
  ];

  const totalRequests = allSessions.reduce(function(sum, s) {
    return sum + s.requestCount;
  }, 0);

  const totalCharged = allSessions.reduce(function(sum, s) {
    return sum + s.totalCharged;
  }, 0);

  console.log("Total requests across all sessions: " + totalRequests);
  console.log("Total charged: $" + totalCharged.toFixed(4));

  if (allSessions.length > 0) {
    const avgRequests = totalRequests / allSessions.length;
    console.log("Average requests per session: " + avgRequests.toFixed(1));
  }
}

generateUtilizationReport();

Code Examples

The following examples demonstrate how to query your account sessions using different programming languages. All examples show complete, working code that you can copy and run directly. Remember to replace YOUR_API_KEY with your actual BBRE API key. Each example includes the basic session listing call and demonstrates how to work with the response data.

JavaScript (fetch)

Retrieve your sessions using the native fetch API. This example demonstrates fetching all sessions without any filter, fetching only active sessions, and iterating through the results with pagination.

const API_BASE = "https://bbre-solver-api.mydisct.com";
const API_KEY = "YOUR_API_KEY";

async function getSessions(options) {
  const response = await fetch(API_BASE + "/account/sessions", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "x-api-key": API_KEY
    },
    body: JSON.stringify(options || {})
  });

  const data = await response.json();

  if (!data.success) {
    console.log("Error:", data.error.code, data.error.message);
    return null;
  }

  return data;
}

async function listAllSessions() {
  const data = await getSessions();

  if (!data) return;

  console.log("Total sessions: " + data.pagination.total);

  for (const session of data.sessions) {
    console.log(
      session.id + " | " +
      session.mode + " | " +
      session.status + " | " +
      "requests: " + session.requestCount + " | " +
      "charged: $" + session.totalCharged.toFixed(4)
    );
  }
}

async function listActiveSessions() {
  const data = await getSessions({ status: "active" });

  if (!data) return;

  console.log("Active sessions: " + data.pagination.total + "/10");

  for (const session of data.sessions) {
    console.log(
      session.id + " | " +
      session.mode + " (" + session.sensibility + ") | " +
      session.requestCount + " requests | " +
      "expires: " + session.expiresAt
    );
  }
}

listAllSessions();
listActiveSessions();

JavaScript - Paginated Fetching

When you have many sessions, you need to paginate through the results. This example demonstrates how to fetch all sessions across multiple pages by incrementing the offset until all results have been retrieved.

const API_BASE = "https://bbre-solver-api.mydisct.com";
const API_KEY = "YOUR_API_KEY";

async function fetchAllSessions(statusFilter) {
  const allSessions = [];
  const pageSize = 20;
  let offset = 0;
  let total = null;

  while (total === null || offset < total) {
    const body = { limit: pageSize, offset: offset };
    if (statusFilter) {
      body.status = statusFilter;
    }

    const response = await fetch(API_BASE + "/account/sessions", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "x-api-key": API_KEY
      },
      body: JSON.stringify(body)
    });

    const data = await response.json();

    if (!data.success) {
      console.log("Error on page fetch:", data.error.code);
      break;
    }

    allSessions.push(...data.sessions);
    total = data.pagination.total;
    offset += pageSize;

    console.log("Fetched " + allSessions.length + "/" + total + " sessions");
  }

  return allSessions;
}

async function main() {
  const sessions = await fetchAllSessions("closed");
  console.log("Total closed sessions retrieved: " + sessions.length);

  const totalCharged = sessions.reduce(function(sum, s) {
    return sum + s.totalCharged;
  }, 0);
  console.log("Total charged across closed sessions: $" + totalCharged.toFixed(4));
}

main();

Python (requests library)

Retrieve and process your sessions using the Python requests library. This example shows how to list sessions with filtering and how to paginate through results.

import requests

API_BASE = "https://bbre-solver-api.mydisct.com"
API_KEY = "YOUR_API_KEY"

headers = {
    "Content-Type": "application/json",
    "x-api-key": API_KEY
}

response = requests.post(
    API_BASE + "/account/sessions",
    headers=headers,
    json={"status": "active"}
)

data = response.json()

if data["success"]:
    print(f"Active sessions: {data['pagination']['total']}/10")
    for session in data["sessions"]:
        print(
            f"  {session['id']} | "
            f"{session['mode']} ({session['sensibility']}) | "
            f"{session['requestCount']} requests | "
            f"${session['totalCharged']:.4f}"
        )
else:
    print(f"Error: {data['error']['code']}")

import requests

API_BASE = "https://bbre-solver-api.mydisct.com"
API_KEY = "YOUR_API_KEY"

headers = {
    "Content-Type": "application/json",
    "x-api-key": API_KEY
}

def fetch_all_sessions(status_filter=None):
    all_sessions = []
    page_size = 20
    offset = 0

    while True:
        body = {"limit": page_size, "offset": offset}
        if status_filter:
            body["status"] = status_filter

        response = requests.post(
            API_BASE + "/account/sessions",
            headers=headers,
            json=body
        )
        data = response.json()

        if not data["success"]:
            print(f"Error: {data['error']['code']}")
            break

        all_sessions.extend(data["sessions"])
        total = data["pagination"]["total"]
        offset += page_size

        if offset >= total:
            break

    return all_sessions

sessions = fetch_all_sessions("closed")
print(f"Retrieved {len(sessions)} closed sessions")

total_charged = sum(s["totalCharged"] for s in sessions)
print(f"Total charged: ${total_charged:.4f}")

cURL

Quick session listing from the command line using cURL. These examples show how to list all sessions, filter by status, and paginate through results.

curl -X POST https://bbre-solver-api.mydisct.com/account/sessions \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY"

curl -X POST https://bbre-solver-api.mydisct.com/account/sessions \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{"status": "active"}'

curl -X POST https://bbre-solver-api.mydisct.com/account/sessions \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{"status": "closed", "limit": 10, "offset": 0}'

curl -X POST https://bbre-solver-api.mydisct.com/account/sessions \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{"limit": 5, "offset": 20}'

Node.js SDK Usage

The mydisctsolver-bbre Node.js SDK does not currently expose a dedicated method for listing account sessions. However, you can use the SDK's underlying HTTP client capabilities or combine the SDK's session management methods with direct API calls to achieve the same result. The following examples show how to integrate session listing into your SDK-based workflow.

Combining SDK Session Management with Direct API Calls

Use the SDK for session creation and management while calling the sessions listing endpoint directly for monitoring and cleanup tasks. This hybrid approach gives you the convenience of the SDK for day-to-day operations and the flexibility of direct API calls for administrative tasks.

const { BBREClient } = require("mydisctsolver-bbre");

const API_BASE = "https://bbre-solver-api.mydisct.com";
const API_KEY = "YOUR_API_KEY";

const client = new BBREClient({ apiKey: API_KEY });

async function getActiveSessionCount() {
  const response = await fetch(API_BASE + "/account/sessions", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "x-api-key": API_KEY
    },
    body: JSON.stringify({ status: "active" })
  });
  const data = await response.json();
  return data.pagination.total;
}

async function createSessionWithCheck() {
  const activeCount = await getActiveSessionCount();

  if (activeCount >= 10) {
    console.log("Cannot create session. Active: " + activeCount + "/10");
    return null;
  }

  const session = await client.createSession({
    mode: "adaptive",
    sensibility: "medium"
  });

  console.log("Session created via SDK: " + session.sessionId);
  return session;
}

createSessionWithCheck();

SDK Session Cleanup Workflow

Combine the sessions listing endpoint with the SDK's closeSession() method to build an automated cleanup workflow that identifies and closes unused sessions.

const { BBREClient } = require("mydisctsolver-bbre");

const API_BASE = "https://bbre-solver-api.mydisct.com";
const API_KEY = "YOUR_API_KEY";

const client = new BBREClient({ apiKey: API_KEY });

async function getActiveSessions() {
  const response = await fetch(API_BASE + "/account/sessions", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "x-api-key": API_KEY
    },
    body: JSON.stringify({ status: "active" })
  });
  const data = await response.json();
  return data.sessions;
}

async function cleanupUnusedSessions() {
  const sessions = await getActiveSessions();
  let closedCount = 0;

  for (const session of sessions) {
    if (session.requestCount === 0) {
      await client.closeSession(session.id);
      console.log("Closed unused session: " + session.id);
      closedCount++;
    }
  }

  console.log("Cleaned up " + closedCount + " unused sessions");
  return closedCount;
}

cleanupUnusedSessions();

Error Codes

The following table lists all error codes that can be returned by the account sessions endpoint, along with their HTTP status codes, descriptions, and recommended solutions. Because the sessions endpoint has no required parameters and is lenient about unrecognized filter values, the most common errors are authentication-related errors and server-side errors. Implementing proper error handling for these codes ensures your session management logic degrades gracefully when issues occur.

Error Handling Example

The following example demonstrates robust error handling for the sessions endpoint. In production systems, your session listing logic should handle each error code appropriately and fall back to a safe default behavior when the session list cannot be retrieved.

const API_BASE = "https://bbre-solver-api.mydisct.com";
const API_KEY = "YOUR_API_KEY";

async function getSessionsSafe(options) {
  try {
    const response = await fetch(API_BASE + "/account/sessions", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "x-api-key": API_KEY
      },
      body: JSON.stringify(options || {})
    });

    const data = await response.json();

    if (data.success) {
      return {
        sessions: data.sessions,
        pagination: data.pagination,
        error: null
      };
    }

    const errorCode = data.error.code;

    if (errorCode === "API_KEY_REQUIRED" || errorCode === "INVALID_API_KEY") {
      return { sessions: [], pagination: null, error: "Authentication failed: " + errorCode };
    }

    if (errorCode === "ACCOUNT_SUSPENDED" || errorCode === "ACCOUNT_INACTIVE") {
      return { sessions: [], pagination: null, error: "Account issue: " + errorCode };
    }

    return { sessions: [], pagination: null, error: "Unexpected error: " + errorCode };

  } catch (networkError) {
    return { sessions: [], pagination: null, error: "Network error: " + networkError.message };
  }
}

async function main() {
  const result = await getSessionsSafe({ status: "active" });

  if (result.error) {
    console.log("Could not list sessions:", result.error);
    return;
  }

  console.log("Active sessions: " + result.pagination.total);
  for (const session of result.sessions) {
    console.log("  " + session.id + " (" + session.mode + ")");
  }
}

main();

Best Practices

Common Issues

Issue 1: SESSION_LIMIT_REACHED When Creating a New Session

Solution: Use the sessions endpoint to list all active sessions and identify which sessions are consuming your slots. It is common for sessions to accumulate when your application crashes or restarts without properly closing its sessions. These orphaned sessions remain active until they expire. Call POST /account/sessions with {"status": "active"} to see all active sessions, then close any that your application is no longer using. Implement a startup routine that checks for and closes orphaned sessions from previous application runs. You can identify orphaned sessions by comparing the session IDs in the API response against the session IDs your current application instance is tracking.

Issue 2: Empty Sessions Array Despite Having Created Sessions

Solution: First, verify that you are using the correct API key. The sessions endpoint returns only sessions that belong to the account associated with the provided API key. If you have multiple API keys or multiple accounts, make sure you are using the same key that was used to create the sessions. Second, check your status filter. If you are filtering by "active" but all your sessions have been closed or expired, the result will be empty. Try removing the status filter to see all sessions regardless of status. Third, check the offset parameter. If you accidentally set a large offset value, you might be skipping past all your sessions.

Issue 3: Sessions Show as Expired Unexpectedly

Solution: Sessions have a finite lifetime that is determined at creation time. If your workflow takes longer than the session timeout, the session will expire before you finish. Check the expiresAt field of your sessions to understand their lifetime. If your workflows consistently need more time, consider increasing the session timeout when creating sessions by setting a higher timeout value in the POST /session/create request. Also, make sure your application is actively sending requests within the session at regular intervals, as some session configurations may extend the expiration time when activity is detected. Monitor the expiresAt field of your active sessions and plan your workflow to complete before the expiration time.

Related Documentation

• Create Session - Create new BBRE sessions with configurable mode, sensibility, fingerprint, proxy, and timeout settings to establish stateful browsing contexts for multi-step workflows
• Close Session - Explicitly close active sessions to free up session slots and release associated resources when your workflow is complete
• Session Status - Check the current status of a specific session including its mode, sensibility, request count, total charges, and expiration time
• Session Request - Send HTTP requests within an active session to maintain cookies, browser context, and fingerprint profile across multiple requests
• Account Info - Retrieve detailed account information including your username, email, status, balance, and usage statistics such as total requests, success rate, and active session count
• Account Balance - Check your current account balance to ensure you have sufficient funds for session creation and per-request charges
• Usage History - View your complete request history with per-request cost breakdowns, processing times, and status information to understand how your balance is being consumed across sessions
• BBRE Engine Overview - Understand the BBRE architecture, operating modes, sensibility levels, and how sessions fit into the overall request processing pipeline