Pagination and selection

Collection methods commonly accept limit and start. The HTTP equivalents are _limit and _start.

Walk through a collection

Use a bounded page size and a stable sort. Stop when the server returns fewer records than the requested limit.

list-cases.ts

import { createConfiguration, TestCasesApi } from '@testcollab/sdk';

const api = new TestCasesApi(createConfiguration(process.env.TESTCOLLAB_TOKEN!));
const limit = 100;

for (let start = 0; ; start += limit) {
  const page = await api.getTestCases({
    project: 123,
    limit,
    start,
    sort: 'id:asc',
  });
  for (const testCase of page) {
    console.log(testCase.id, testCase.title);
  }
  if (page.length < limit) break;
}

This pattern keeps memory use bounded and avoids assuming that a project fits into the first page. Changes made while you paginate can still affect an offset-based collection; use an appropriate snapshot or timestamp window when your workflow needs stronger consistency.

Count before a large job

Use the corresponding count method when you need an estimate before processing a project. A count is useful for progress reporting, but is not a substitute for reading every page.

Filters

Some methods accept a filter argument containing a JSON string. Use the filtering shape supported by that method and serialize it with JSON.stringify. Do not pass an object to a parameter that expects a string.

Other methods have explicit selectors or IDs. For a small, known set of cases, pass the case IDs directly as shown in create a test plan.

Keep selection scoped

Always carry the project ID through the workflow. Resolve suite IDs, member IDs and case IDs within that project rather than reusing a name match from a different project or region.