API overview
Control Synq with the Node.js SDK or REST API.
Create projects, deploy code, and operate your installation from an application or script. Each resource has one reference page: shared behavior and fields, with SDK and REST API tabs for examples.
Start here
| Your application needs to… | Use |
|---|---|
| Control an existing Synq installation | Remote SDK client or REST API |
| Run Synq inside a Node application | Native SDK |
| Run commands from a terminal or CI | CLI |
The SDK isn't published to npm. See installation.
Make a request
Use a token that can read projects in your organization. The SDK returns the application result; REST returns the endpoint's JSON response.
import { SynqClient } from "synq";
const token = process.env.SYNQ_TOKEN;
const organizationId = process.env.SYNQ_ORGANIZATION_ID;
if (!token || !organizationId) throw new Error("Set a token and organization ID");
const ship = new SynqClient({
baseUrl: "https://app.example.com",
token,
organizationId,
});
const projects = await ship.projects.list({ page: 1, perPage: 20 });
console.log(projects.data);export SYNQ_URL="https://app.example.com"
export SYNQ_ORGANIZATION_ID="org_123"
# Set SYNQ_TOKEN to your personal access token.
curl "$SYNQ_URL/api/projects?page=1&perPage=20" \
-H "Authorization: Bearer $SYNQ_TOKEN" \
-H "X-Organization-Id: $SYNQ_ORGANIZATION_ID" \
-H "X-Synq-Scope: fixed"Example conventions
Resource examples use ship for a configured remote client or native user scope.
Replace IDs such as proj_123 with your own. REST examples use the URL and token above; a token's
organization binding applies to every request. To pin an organization independently of defaults,
include the two scope headers shown above. Older APIs must support fixed scopes.
Named SDK methods unwrap response envelopes where applicable. For example, projects.get(id) returns a
project, while its REST endpoint returns { data: project }. IDs may be method arguments in the SDK
and URL, query, or body fields in REST; the code tabs show that mapping.
Applications
| Resource | Use |
|---|---|
| Projects | Configuration, environments, connections, and storage bindings |
| Source files | Generated code, folder uploads, and source detection |
| Deployments | Builds, progress, decisions, cancellation, and rollback |
| Services | Containers and services within a project |
| App catalog | Templates and application settings |
| GitHub | Accounts, repositories, and GitHub App sources |
Networking
| Resource | Use |
|---|---|
| Domains and TLS | Hostnames, DNS verification, and certificates |
| DNS providers | DNS credentials and zone checks |
| Webhooks | Incoming actions and provider deliveries |
| Edge administration | Discover and import existing edge sites |
| Server terminal / service terminal | Interactive WebSocket sessions |
Operations
| Resource | Use |
|---|---|
| Analytics | Traffic and resource usage |
| Issues and health | Problems, health snapshots, and rescans |
| Updates | Available versions and update deployment |
| Jobs | Commands, schedules, and run history |
| Backups / destinations | Policies, archives, and restores |
| Notifications | Channels, subscriptions, and deliveries |
| Notices | Public installation announcements |
| Audit log | Organization activity |
Access and infrastructure
| Resource | Use |
|---|---|
| Tokens / permissions | Credentials, members, invitations, and grants |
| Provider credentials | Registry and DNS provider secrets |
| User settings | Build, deploy, routing, and Git defaults |
| Servers / installation settings | Hosts, components, setup, and administration |
| Health / container images | Installation metadata and image catalog |
| Self-hosted email services | |
| Migration / data transfer | Server adoption, moves, imports, and exports |
| Cloud / billing | Cloud connections, plans, and usage (hosted-cloud only, switched off in Synq) |
| Authentication / MCP | Browser login and agent protocols |
For transport details, see HTTP basics. For errors, providers, and current native limits, see SDK errors and compatibility.