Choose your SDK

Prefer the language your team already uses. For a new project, choose based on the integration you want to build and maintain.

All four SDKs cover the same API areas. Language choice primarily affects the surrounding application: the libraries you use, how you deploy it, and who can maintain it. The recommendations below are starting points, not exclusive capabilities or a ranking of the languages.

Quick decision guide

Your situation	Good starting choice	Why
Data exports, reporting, data cleanup, exploratory scripts	Python	Strong data-processing ecosystem and quick iteration
Web applications, dashboards, Node.js backends	TypeScript	Fits web stacks and provides compile-time feedback
Standalone CLI tools, scheduled services, deployable integration binaries	Go	Straightforward binary deployment and explicit concurrency
Existing Laravel, Symfony, or other PHP applications	PHP	Integrates naturally into the application you already maintain

With no existing stack, Python is a reasonable default for a small script, and TypeScript is a reasonable default for a web-oriented project. Before committing, check your hosting environment and the runtime requirements of the selected SDK.

Start with four questions

1. Does this belong in an existing application? Use that application’s language unless there is a concrete requirement it cannot meet. A nightly inventory export in a Laravel application is a good PHP task, even though Python is often convenient for standalone exports.
2. What happens around the API calls? Data analysis libraries favour Python; a Node.js web stack favours TypeScript; an existing PHP application favours PHP; distributing a standalone command-line binary can favour Go.
3. Where will it run? Check available runtimes, framework versions, deployment tooling, and whether you can install packages or deploy a binary. Choosing the language already supported by your platform simplifies operations.
4. Who will maintain it? Prefer a language the responsible team can review, debug, test, and support after the initial implementation.

Python: scripts and data workflows

Python is a natural choice for exporting inventory, cleaning up input data, combining API data with other sources, or exploring a new integration. Its ecosystem includes tools for tabular data, spreadsheets, and analysis.

Example: fetch all inventory objects, combine them with purchasing data, and produce a report for a finance team.

The Python SDK provides both synchronous and asynchronous clients. Start with the synchronous client for a straightforward script; choose async when it fits the application’s execution model. Deploy a compatible Python environment and install the pinned dependencies. Type hints and static analysis can help with maintenance, but are separate from executing the script.

Start with the Python SDK guide or the Python quickstart.

TypeScript: web-oriented applications

TypeScript fits Node.js services, web applications, and dashboards, especially when the team already uses JavaScript or TypeScript. Compile-time feedback helps catch incorrect SDK usage while editing and building the application.

Example: add an inventory search screen to an existing web application, with a backend that calls the Customer API.

The quickstart runs on Node.js 22+. The SDK also supports other runtimes, as described in its language guide. A TypeScript frontend can use a backend written in any of the four languages; choosing a frontend language does not require changing an existing backend. Keep service credentials on the backend. Static types do not replace discovering and validating instance-specific fields.

Start with the TypeScript SDK guide or the TypeScript quickstart.

Go: standalone tools and services

Go is a good fit when you want to distribute an integration as a compiled command-line program or operate a standalone service. Its concurrency features are useful when the application needs explicitly controlled parallel work.

Example: distribute an inventory synchronization tool to operations teams as a binary built for each supported operating system and architecture.

The Go SDK uses the standard library. Building requires a compatible Go toolchain, while the compiled application does not require installing the Go toolchain on its target machine. Plan for separate target builds and the application’s configuration. Explicit error handling and compilation can add structure compared with a short exploratory script.

Start with the Go SDK guide or the Go quickstart.

PHP: integrations within PHP applications

PHP is the straightforward choice when an integration belongs in a Laravel, Symfony, or other PHP application. Reuse the application’s configuration, scheduler, queues, logging, and deployment process.

Example: synchronize asset assignments from an existing PHP business application using its queue workers and scheduled jobs.

PHP also supports standalone scripts and CLI jobs. The pinned SDK requires PHP 8.5+, so verify compatibility with your existing application’s runtime before installing it. Composer manages the SDK and its dependencies. There is usually little benefit in introducing a second language just to call the API.

Start with the PHP SDK guide or the PHP quickstart.

What should not decide the language by itself?

• Scheduled execution: all four languages can run scheduled integrations. Use the scheduler and deployment model that fit your environment.
• Expected API speed: network latency, pagination, request volume, and API limits often matter more than language execution speed. Measure the real workload before introducing another language for performance.
• AI-generated code: AI coding tools can help with all four languages. The team still needs to understand, test, and maintain the output.
• Custom fields: all SDKs support instance-defined data. None can infer a customer’s complete schema from the language’s types alone.

Ask your AI coding tool for a recommendation

Describe the integration rather than asking for the “best language” in the abstract. For example:

We need a nightly inventory export. Our team maintains a Laravel application on PHP 8.5, with queue workers and an existing scheduler. Recommend an SDK based on this guide, explain the tradeoffs, and start from the matching customer-api-quickstart example.

Include your task, current stack, hosting environment, and team experience. If you are starting from scratch, say so and describe who will maintain the result.

Once you have chosen, follow the AI quickstart. The quickstart repository’s decision guide summarizes the same recommendations next to the runnable starters.