CPQ SDK for Developers
First API call took three days. Most of it was auth and pagination. Use Mercura SDK clients so your team configures products and creates quotes in code without rewriting REST plumbing on every endpoint.
Typed client
Configuration objects in your IDE
Auth handled
Token refresh in the SDK
Shared helpers
Pagination and errors once
The challenge
First API call took three days. Most of it was auth and pagination.
An OEM of form-fill and sealing machinery for food packaging runs Mercura CPQ and wants a TypeScript dealer portal where partners configure lines and request quotes. The internal team starts on raw REST: OAuth token exchange, refresh on 401, page cursors on product lists, and JSON shapes that do not match what Postman showed. By Wednesday they still have no working configuration session because every developer copied slightly different helper code from Stack Overflow.
Without typed clients, field renames break production at runtime. Pagination bugs drop half the catalog from search results. Webhook handlers parse events by hand and miss fields when the API adds properties. Each sprint adds more fetch wrappers nobody wants to maintain while product waits for quote creation in the portal.
API-first CPQ exposes configuration, pricing, and quote endpoints for any channel. Headless CPQ separates engine logic from Mercura UI so you build your own front end. CPQ developer tools provide sandbox and testing utilities. The SDK is different: language-native clients generated from the OpenAPI spec handle auth, serialisation, pagination, retries, and typed errors so integration code focuses on dealer workflows, not HTTP mechanics.
Inquiry to config to price to approval to order should not stall because the portal team is still writing the same auth helper the ERP team wrote last quarter.
How it works
How the Mercura CPQ SDK works
Install the SDK for Python, TypeScript, Java, or .NET from package registries. Initialise a client with tenant credentials; the SDK manages token acquisition and refresh. Call typed methods for forms, configuration sessions, price calculation, and quote creation. List helpers walk paginated catalog endpoints. Webhook utilities deserialize events into typed objects. Errors return typed classes your IDE can catch before deploy. SDK versions track API releases so breaking changes surface at compile time. Someone must still design dealer UX, map business rules, and test against the sandbox before production cutover.
What's included
What the CPQ SDK covers
- Typed clients for Python, TypeScript, Java, and .NET
- Authentication and token refresh handled by the SDK
- Pagination helpers for catalog and quote list endpoints
- Typed error classes with response detail attached
- Webhook event parsing into typed objects
- Retry with backoff for transient HTTP failures
- Code examples for configure, price, and quote flows
- SDK versioning aligned with Mercura API releases
The difference
Integration code before and after the SDK
- Each developer rewrites auth and pagination helpers
- Field typos found in production, not in the IDE
- Webhook parsers break when API adds properties
- Integration sprints consumed by HTTP plumbing
- Technical debt grows in ad hoc fetch wrappers
- One client library shared across portal and middleware
- Type coverage for configuration and quote objects
- Catalog list calls use SDK pagination helpers
- Webhook handlers use generated event types
- Team ships dealer features instead of HTTP boilerplate
Real-world application
Example workflow: dealer portal for packaging lines
A form-fill machinery OEM needed a partner portal where dealers configure sealing and filling modules and submit quote requests. The team started with hand-written fetch calls and spent the first sprint on OAuth and paging through product attributes. After switching to the Mercura TypeScript SDK, the same developers opened a configuration session and returned priced lines using typed methods, moved webhook handling to generated event types, and redirected remaining time to dealer-specific validation rules instead of HTTP utilities.
Business impact
Why the SDK is developer velocity, not a substitute for API design
The SDK turns Mercura REST into patterns your team already uses in Python, TypeScript, Java, or .NET. It complements API-first architecture, headless deployment, developer sandbox tools, and embedded configurators. Mercura does not replace solution design, security review, or ERP field mapping outside the client library. Someone must own portal UX and integration tests. If the pain is "three days in and we still have no configure call", the SDK removes repeated auth and pagination work so inquiry, configuration, price, approval, and order logic ships in the channel you are building.
See a TypeScript SDK client open a configuration session without writing auth from scratch
Book a demo and walk through SDK install, sandbox credentials, and a configure-to-quote call in your language.
Let’s build together.
We empower manufacturers to master product modeling, streamline quoting process, reduce errors, and ultimately deliver the tailored solutions that customers demand.