Shipping the PostQ SDKs: JavaScript, Python, and .NET

A day after cutting v0.1 of the PostQ CLI, we’re shipping the next layer: official SDKs for the three languages our early users actually write services in. They’re live now on npm, PyPI, and NuGet:

• @postq/sdk on npm — TypeScript-first, Node 18+
• postq-sdk on PyPI — pure-Python, 3.9+
• PostQ.Sdk on NuGet — .NET 8+

Why three SDKs and not one?

The CLI and the dashboard cover a lot, but neither lets you embedPostQ into something else — a custom scanner, a policy engine, a CI gate, an internal compliance dashboard. For that you want a real SDK in the language your service is written in, installable from your package manager, with types and idiomatic error handling.

So we shipped exactly that, in the three languages our early-access users picked up the API in: TypeScript backends, Python data pipelines, and .NET services in regulated industries.

What’s in v0.2

The 0.2 line is intentionally small. It wraps the two endpoints you actually need to integrate with PostQ today:

• pq.scans.submit(...) — push results from your own scanner, CI job, or compliance script into PostQ. Get back a permalink and a deduplicated record in your dashboard.
• pq.scans.list(...) and iterAll() / iter_all() / IterAllAsync() — cursor-based reads over your scan history. Single page or auto-paginated stream.
• pq.health() — one call to verify your key and connectivity.

That’s the entire surface. No speculative methods for endpoints that don’t exist yet. Hybrid signing, key listing, and policy APIs will land in their own minor versions when the API endpoints ship behind them.

Same shape, three languages

Each SDK looks native to its ecosystem (camelCase in JS, snake_case in Python, PascalCase + async in .NET) but the operations and arguments line up exactly. Once you know one, you know all three.

import { PostQ } from "@postq/sdk";

const pq = new PostQ({ apiKey: process.env.POSTQ_API_KEY! });

const result = await pq.scans.submit({
  type: "url",
  target: "example.com",
  riskScore: 85,
  riskLevel: "High",
  findings: [{ severity: "high", title: "RSA-2048 public key" }],
});

console.log(result.url);

from postq import PostQ, Finding

pq = PostQ()  # reads POSTQ_API_KEY

result = pq.scans.submit(
    type="url",
    target="example.com",
    risk_score=85,
    risk_level="High",
    findings=[Finding(severity="high", title="RSA-2048 public key")],
)
print(result.url)

using PostQ;

var pq = new PostQClient(Environment.GetEnvironmentVariable("POSTQ_API_KEY")!);

var result = await pq.Scans.SubmitAsync(new ScanSubmit {
    Type = "url",
    Target = "example.com",
    RiskScore = 85,
    RiskLevel = "High",
    Findings = new[] {
        new Finding { Severity = "high", Title = "RSA-2048 public key" },
    },
});

Console.WriteLine(result.Url);

Built for CI gates

The most common pattern we see: a small script in CI that submits a scan and fails the build if PostQ flags a Critical or High issue. The SDKs are designed to make that a five-line script.

import { PostQ } from "@postq/sdk";
const pq = new PostQ({ apiKey: process.env.POSTQ_API_KEY! });

const result = await pq.scans.submit({ type: "url", target: "api.example.com" });
if (["Critical", "High"].includes(result.riskLevel)) {
  console.error(`::error::PostQ found ${result.riskLevel} risk: ${result.url}`);
  process.exit(2);
}

Same pattern works in Python and .NET (full examples on the SDKs page). It’s the same exit-code-2 contract the CLI uses, so you can mix and match.

Provenance, not promises

Every release is built and published from a tag-triggered GitHub Actions workflow in our public postq-sdk-all repo. The npm package ships with a Sigstore provenance attestation; PyPI uses Trusted Publishing (OIDC, no long-lived secrets); NuGet uses a scoped, short-lived API key. You can verify any of them against a specific commit.

What’s next

v0.3 will track the API as it grows: hybrid signing, key listing, and policy enforcement endpoints. The shape stays semver-stable — new methods are additive, and any breaking change moves to v1.

Beyond that, we’re watching demand for a Go SDK (most of it already exists in the CLI’s internals) and a Rust SDK. If you want one, tell us in the GitHub repo or email us — that’s how the .NET SDK got prioritized over Ruby this quarter.

Try it

Pick your stack:

npm install @postq/sdk
pip install postq-sdk
dotnet add package PostQ.Sdk

Grab a pq_live_… key from your PostQ team, and you’re submitting your first scan in under five minutes. Full reference and tutorials on the SDKs page.

Bug reports, feature requests, missing-language complaints → github.com/PostQDev/postq-sdk-all/issues.