Twinn Engineering
Book a demo
Early access

Ask Twinn: ask your Sage 100 Contractor books a question

Ask Twinn is the assistant inside the Twinn web app. Ask it “which jobs are over budget right now?” and it runs the right Twinn report against your live Sage 100 Contractor data, answers in plain English, and tells you which report it ran, with which criteria, as of when.

It is read-only and works inside each person’s own permissions; payroll stays a separate permission, every question is logged, and conversations are deleted 30 days after the last message.

Alongside it, the Twinn report library now has 46 reports, each with its own page: what it shows, every column, and how it is calculated.

Meet Ask Twinn Request early access
Product release

OPDC API v3 is live

As of August 5, 2026, v3 is the current contract for the OPDC API. It is a full rewrite of the request and response shapes around one idea: everything an integrator needs to know should be visible in the status code, the envelope, or the error body.

v3 ships beside v2, not instead of it. Nothing you have running today stops working.

What changed

Six changes you will notice on the first call

The whole surface is two shapes plus a list of nouns: one read envelope, one write envelope, and one error body.

Status codes mean what they say

A business failure is a 4xx or a 5xx, so res.ok is a correct check and every HTTP client, proxy, and retry library already understands the answer.

One error body

application/problem+json on every status, with a stable machine-matchable code you can branch on. One parser handles every failure your client will ever see.

One read and one write envelope

Every query returns asOf, page, and data. Every write returns the document plus its journal, job costs, and inventory movements under the same keys.

Idempotency keys on writes

Retry a timed-out post with the same key and get the original response back, so a flaky connection cannot turn one invoice into two.

Dry run on any write

Add dryRun=true to execute the whole cascade against live data inside a transaction that is rolled back, and see exactly what would have posted.

Every field is validated

Requests are checked against the contract before they run. A misspelled field comes back as a 400 that names it, so you find the typo in development instead of in a report.

If you are on v2

Nothing breaks today

/api/v2 stays available as a frozen compatibility surface. It is not being deleted out from under you, so no existing integration has to move to keep working.

v2 is scheduled for removal in December 2026. New integrations should start on v3, and existing ones have time to migrate deliberately.

Move one read at a time

  1. Keep your existing v2 client running while you add a v3 client beside it.
  2. Change the path to /api/v3/{entity}/query and use the v3 resource name.
  3. Translate page.count to page.totalCount. v3 page numbers start at 1.
  4. Parse non-2xx responses as the documented problem body and log X-Correlation-Id.
  5. Run both clients against the same filter and compare counts before switching traffic.

The full migration checklist, with request and response examples for every step, lives in the v3 guide.

Where to start

Read the contract

Thirteen domains are documented, each with its own OpenAPI document you can load into your client generator.

The v3 guide

Getting started, entities, filters, writes, and errors, with copyable examples in curl, Python, and JavaScript.

The OpenAPI document

The complete v3 contract, machine readable. This is the contract itself, not a description of it.

Help with a migration

Tell us what your v2 client does today and we will map it to v3 endpoints with you.

Try v3 against your own data

Book a call and we will run v3 queries against a copy of your Sage company, so you can see exactly what comes back.

Schedule a Demo Read the Guide