Choose an integration approach and calling identity, complete service account setup, and add business capabilities as needed.
Use Qoder Agent SDK to receive tasks, call business tools, and deliver results in your applications, internal tools, or automated services. See Overview and How it works for capabilities and execution.
Find your requirement, choose an approach, and follow the linked instructions:
Combine capabilities as needed; you do not need to integrate all of them.
A Personal Access Token (PAT) represents a Qoder user. Use it for scripts, CI, or applications that need that user's permissions and data. A developer workstation can also reuse the local Qoder CLI sign-in. Automated services should configure credentials explicitly.
A service account (SA) is an independent application identity within an organization, suited to backend services, CI, and scheduled jobs that should not depend on a personal account. Business users continue to sign in to your application and do not each need a Qoder account. Your application handles user authentication and task authorization. See Members and roles and Service accounts.
Complete the steps below in order, reusing existing configuration where applicable. The subscription, billing, service account, and credentials must belong to the same target organization.
Confirm that the target organization has an active Teams or Enterprise subscription and was created through a Cloud Marketplace redemption code. Check the prerequisites for SA mode. See About redemption codes for organization creation and purchasing, and Plans and pricing for plan details.
Choose JavaScript/TypeScript (Node.js), Python, or Java, then follow the installation instructions. Use one of these authentication methods:
Combine these capabilities as needed. Follow the linked documentation for configuration:
Not when integrating with an SA. Users keep their application accounts, and the SA accesses Qoder on behalf of the application. Your application remains responsible for sign-in, data access, and task authorization. See Organization applications.
First confirm that the organization meets the prerequisites, purchase and redeem dedicated service account Credits, and confirm that the balance is available. Then create the service account and credentials and configure the SDK. Follow Start integrating with a service account.
Not necessarily. The initial business check only decides whether to start the task. Subsequent calls must still meet credential, dedicated Credits balance, and account quota requirements.
The project files must remain accessible, with consistent project directory semantics. External session storage does not migrate the workspace.
No. The platform continues to record consumption against the service account and its organization. Your application maps usage to business users and allocates or records it itself; this does not automatically change platform usage attribution or ownership of Credits pack orders.
Integration scenarios
Find your requirement, choose an approach, and follow the linked instructions:
| Your requirement | Integration approach | Where to start |
|---|---|---|
| Build an Agent application or add Agent capabilities to an existing product | Embed the SDK in a desktop application, web backend, or developer tool | Choose a calling identity, Setup steps |
| Automate tasks in an existing business workflow | Call the SDK from a script, job service, or pipeline | Setup steps, Add business capabilities |
| Track user consumption or restrict access by permissions, plan, or balance | Attribute usage and add checks before starting a task as needed | Usage attribution and task admission |
Choose a calling identity
Individual calls
A Personal Access Token (PAT) represents a Qoder user. Use it for scripts, CI, or applications that need that user's permissions and data. A developer workstation can also reuse the local Qoder CLI sign-in. Automated services should configure credentials explicitly.
Organization applications
A service account (SA) is an independent application identity within an organization, suited to backend services, CI, and scheduled jobs that should not depend on a personal account. Business users continue to sign in to your application and do not each need a Qoder account. Your application handles user authentication and task authorization. See Members and roles and Service accounts.
Manage service account credentials by deployment
- SDK on a trusted backend: Store the SA Key on the backend and pass it directly to the SDK. The SDK obtains and refreshes short-lived service account tokens (SATs).
- Client applications or centralized credentials: Keep the SA Key on a trusted server, validate the business user, and exchange the key for an SAT. The host application provides and refreshes SATs. Do not distribute the SA Key in client applications.
Start integrating with a service account
Complete the steps below in order, reusing existing configuration where applicable. The subscription, billing, service account, and credentials must belong to the same target organization.
Step 1: Check the organization and subscription channel
Confirm that the target organization has an active Teams or Enterprise subscription and was created through a Cloud Marketplace redemption code. Check the prerequisites for SA mode. See About redemption codes for organization creation and purchasing, and Plans and pricing for plan details.
Step 2: Purchase and redeem SA dedicated Credits
- Follow Purchase and redemption to buy a service account dedicated Credits pack on Alibaba Cloud International Marketplace.
- As an organization administrator, open Organization Settings > Organization Usage > Redeem credits pack, redeem it to the target organization, and confirm that the balance is available.
Step 3: Create a service account and credentials
- Have an organization administrator create a service account for the application and set a dedicated Credits quota if needed.
- Generate an SA Key as described in the service account authentication prerequisites and store it in a trusted server-side secret manager.
Step 4: Install the SDK and configure SA authentication
Choose JavaScript/TypeScript (Node.js), Python, or Java, then follow the installation instructions. Use one of these authentication methods:
- SDK on a trusted backend: Pass the SA Key directly.
- Client application or centralized credentials: Have the host provide and refresh SATs.
Step 5: Run a task and check usage
- Run your first task with Quick start, using the SA authentication configured in step 4 and an explicit workspace and tool permissions.
- After receiving the final result, check the task status using Errors and error codes, then review Cost and usage.
- Check SA consumption and the dedicated Credits balance in Organization Usage. Follow enterprise billing guidance to check orders and payments in the marketplace account.
Add business capabilities
Combine these capabilities as needed. Follow the linked documentation for configuration:
| Business requirement | Approach and documentation |
|---|---|
| Access business data or internal systems | Custom tools, MCP |
| Provide business roles, team rules, and working methods | System prompt, Skills |
| Assign specialist roles or distribute extensions together | Subagents, Plugins |
| Approve operations and validate or audit execution | Permissions, Hooks |
| Resume sessions across instances | External session storage |
| Reuse experience or restore file state | Memory, File snapshots and rewind |
| Configure model policies or check code security | Model selection, Security scan |
| Track consumption by user or customer | Map users, tasks, and sessions, read Cost and usage, and record usage in your business system |
| Restrict use by permissions, plan, or balance | Check business entitlements in the application. Start the task if allowed; otherwise return a reason. Qoder still validates credentials and platform limits |