A CPQ your own systems can drive end to end

Your customers already live somewhere else: a storefront, a dealer portal, a field-service app, an ERP screen. A second interface to configure and price a product breaks the experience, and rebuilding your product rules in your own front end means two copies of the same logic that drift apart within a quarter. The usual answer is a partial API bolted on after launch: some operations are exposed, others are not, and the documentation is a PDF that was accurate on the day it was written.

Integration teams pay too. If the only way to learn that a quote was approved is to poll a list and compare it against yesterday's copy, the ERP falls behind, orders are keyed twice, and nobody trusts the numbers.

Neblex CPQ is a platform first and a screen second. The interface reps use is a client of the same API your systems call, so there is no operation a person can perform that a machine cannot. The specification describing those operations is generated from the product and browsable from Settings, so it cannot drift from the code that serves it.

Four mandatory layers on every machine call. A call from an outside system clears four checks, in order, before any business logic runs: a header naming your environment; a mutual TLS client certificate, issued from inside the product as a PKCS#12 file, valid for 365 days by default, pinned by fingerprint, and checked on every call for revocation and validity dates; a bearer service token; and an optional IP allowance that admits only listed addresses, CIDR blocks, or ranges. An allowance switched on with an empty list refuses every call rather than quietly opening the door. Only then does the platform check that the token's scopes permit the requested action on the module.

Service accounts and tokens. A service account is the identity of an external system in your environment. It is not a user: it cannot sign in and exists only to own tokens and event listeners. Each token carries its own scope matrix, with read, create, update, delete, and execute decided per module, and every scope starts disabled. The full token is shown exactly once, at creation. Expiry is optional. Revocation is immediate and one-way: a revoked token is reissued, never restored, and disabling a service account revokes everything beneath it. Each token records when it was last used successfully, so dormant credentials are easy to spot.

The event feed. Outside systems learn what happened through a pull-based feed. There are no push webhooks. A listener subscribes a service account to the event types it needs; the integration fetches on its own schedule and acknowledges what it consumed. Delivery is at least once until acknowledged, so a consumer that crashes mid-batch simply sees the same events again. Twenty event types are append-only, one ordered record per occurrence: quote created, quote approved, quote rejected, quote deleted, customer created, part created, configuration session completed, and others. Seven are coalesced, keeping only the latest state per record: quote updated, customer updated, part updated, and four more customer detail updates. A fetch returns up to 500 of each kind, and the append-only cursor never moves backward.

Outbound calls to your other systems. Rules and functions can call external services, but never by URL. An administrator registers an endpoint by name with its address, method, authentication, headers, optional body template, cache lifetime, and hourly rate limit; a function then calls it by that name. Authentication can be none, bearer token, basic, or API key header, and credentials are encrypted at rest and decrypted only at the moment of the call. Every call goes over HTTPS with TLS 1.2 or newer and mandatory certificate validation, with no redirects and never to a loopback, private, link-local, or cloud metadata address. Secrets, request parameters, and response bodies are never written to logs.

The query language over your data tables. A constrained query language works over the data tables you maintain in the product. It supports select, insert, update, and delete, each gated by the user's matching permission, with one join, five aggregate functions (count, sum, average, minimum, maximum), and group by. A delete or update without a where clause is refused.

Neblex Integration Fabric. CPQ has no CRM or ERP connectors of its own, by design. The bridge is Neblex Integration Fabric, which consumes the event feed, writes back through a scoped service account, and carries 239 ready-made connectors, so quote-to-cash and order-to-cash flows are assembled, not coded.

• API documentation panel. Open Settings, then Integrations, then API documentation. The specification is browse-only; live calls go through your own client with the certificate and token attached.
• Service accounts and scopes. Create a service account, issue a token, copy it from the one-time display, then edit its scopes. A scope edit replaces the whole matrix at once, so a half-applied change cannot exist.
• Certificates. Issue a client certificate and download the PKCS#12 file with its one-time password. The platform keeps the fingerprint, serial, validity window, and label, never the private key.
• Network restrictions. Switch on the IP allowance and add addresses, blocks, or ranges. Each entry is validated on save, and a malformed entry is named in the error.
• Event listeners. Pick a service account with an active token, name the listener, multi-select the event types, and save. Disabling a listener stops new events; queued events stay until acknowledged.
• External APIs. Register an endpoint with a name, URL, method, authentication, and test parameters. The Test button runs the real call with every security check and shows the response inline; saving an active endpoint re-runs that test as a precondition. An endpoint cannot be deleted while any rule or function references it.
• Matt, the Neblex AI Assistant. Ask Matt how to shape a query, structure a function that calls a registered endpoint, or read an error code, and it drafts the query or function for you to review. Matt advises and drafts; it never saves or changes anything in your environment.

• Every configuration, pricing, and quoting operation available as an API call
• Generated OpenAPI specification, browsable inside the product
• Environment header, mutual TLS client certificate, and bearer service token required on every machine call
• Optional IP allowance with single addresses, CIDR blocks, and ranges, and an empty-list failsafe that refuses all calls
• Per-module and per-action scopes: read, create, update, delete, execute, all opt-in
• Tokens with one-time secret display, optional expiry, immediate one-way revocation, and last-used timestamps
• Client certificates issued as PKCS#12 with 365-day default validity, pinned by fingerprint
• Pull-based event feed with cursors and explicit acknowledgment, at least once until acknowledged
• 20 append-only and 7 coalesced event types across quotes, customers, parts, and configuration sessions
• Named outbound endpoints with authentication types none, bearer, basic, and API key
• Encrypted credentials, body templates, cache lifetime up to 24 hours, hourly rate limits, and a mandatory live test before save
• HTTPS only, TLS 1.2 minimum, certificate validation, no redirects, no internal or metadata addresses
• Up to 10 distinct outbound calls and 25 distinct data queries per evaluation
• Query language with select, insert, update, and delete by permission, one join, five aggregate functions, and group by
• Neblex Integration Fabric as the bridge to CRMs, ERPs, and 239 connectors

A manufacturer sells configurable compressors through its own dealer storefront, and its ERP must learn about every approved quote without anyone re-keying it.

1. 1The integration team reads the specification. They open the API documentation panel in Settings, find the configuration session, pricing, and quote routes, and generate a client from it.
2. 2An administrator creates two service accounts. One for the storefront, scoped to create and update configuration sessions and quotes and to read prices; one for the ERP, scoped to read only. Each system gets its own token and client certificate, and the IP allowance is switched on with the two egress ranges.
3. 3A dealer configures a compressor. The storefront starts a configuration session through the API, sends each choice as the dealer makes it, and renders the visibility, violations, price, and lead time the platform returns. The rules run on Neblex; the storefront draws the result.
4. 4A function checks warehouse stock. A registered endpoint named warehouse-stock, authenticated with an API key header and cached for ten minutes, is called from a function with the selected motor's part number. If stock is low, the function adds a lead-time component, and the dealer sees the longer date before a quote exists.
5. 5The storefront creates the quote. Once the session is valid, the storefront adds it as a quote line and submits the quote for approval. A quote approval requested event lands in the feed.
6. 6A sales manager approves in Neblex. The approval writes a quote approved event, an append-only record with the quote's identifier and payload.
7. 7The ERP fetches and acknowledges. Every 30 seconds the ERP integration fetches from its listener, processes the append-only stream in order, upserts any coalesced quote updated or customer updated records, and acknowledges what it handled. If it was down for an hour, the next fetch resumes from the cursor it last acknowledged.
8. 8A dormant token is cleaned up. Months later an administrator spots a test token on the ERP account unused since spring and revokes it. Revocation is immediate and cannot be undone.