From API endpoint to runnable integration: six Pritset SDKs and examples
An API integration is not finished when the endpoint works. It is finished when a developer can install a package, run a small example, and get a real result without rebuilding authentication, multipart requests, error handling, and file processing from scratch.
That is what I have been working on for Pritset.
Pritset generates PDFs from reusable DOCX templates and JSON data. You create the document layout in Word, upload it once, and generate personalized PDFs through the API.
Six official SDKs
Pritset now has SDK version 0.1.5 available for six backend languages:
Node.js: @pritset/sdk
PHP: pritset/pritset-php
Python: pritset
Go: github.com/Pritset/pritset-go-sdk
.NET: Pritset
Java: com.pritset:pritset-java
Each SDK follows the same core workflow:
Configure an access token and secret.
Create, validate, update, download, or delete DOCX templates.
Send JSON data to a template.
Receive the generated PDF directly or submit a background job using a webhook.
Handle validation, API, authentication, and transport errors using language-specific types.
All six SDKs have been tested against the production API using a dedicated test account. Their repositories also run guarded production lifecycle tests for pull requests targeting the main branch.
Documentation and installation instructions are available at:
Runnable examples for every SDK
Package documentation is useful, but I also wanted to show what each SDK looks like inside a clean consumer project.
The updated examples repository contains runnable projects for Node.js, PHP, Python, Go, .NET, and Java:
https://github.com/daviatorstorm/pritset-examples
Each example:
installs the published 0.1.5 package through the language’s package manager;
reads credentials and the template ID from environment variables;
loads JSON data from a file;
generates a PDF using the official SDK;
checks the response content type and PDF signature;
saves the result to an ignored output directory;
includes a separate webhook-submission example.
Generated PDFs are treated as runtime output, so they are not committed to the repository.
The examples are intentionally small. They are meant to answer one practical question: “What does the minimum working Pritset integration look like in my language?”
A GitHub Actions workflow installs and validates all six projects independently.
Latest frontend improvements
The latest frontend update makes it easier to work with templates after signing in.
The dashboard now presents request statistics more clearly and adapts better to different screen sizes. Template usage, recent requests, and monthly activity are easier to inspect without charts overflowing or competing for space.
Template workflows were also improved:
preview an uploaded DOCX template in the browser;
test a template with JSON data before integrating it into an application;
test an existing template directly from its details page;
copy template IDs more easily;
open template details directly from the templates list.
The browser preview is clearly treated as a preview because fonts and final rendering may differ from the generated PDF. The API-generated PDF remains the output that should be reviewed before production use.
What comes next
The SDKs, documentation, and examples now cover the complete path from installing a package to generating a PDF.
Pritset is still early, and practical developer feedback matters more than adding another layer of marketing copy. If your application generates invoices, reports, contracts, booking documents, certificates, or other PDFs from structured data, try the example for your stack.
I would especially like to know: what is the first unclear or inconvenient step you encounter while going from the example to your own DOCX template?
Learn more:
Product overview: https://pritset.com/docx-to-pdf
SDK documentation: https://pritset.com/docs/sdks
Runnable examples: https://github.com/daviatorstorm/pritset-examples
Replies