API changelog: 2026

Pausing a filing now follows the same window as the Kintsugi app. After the 15th of the month a filing is due, it can no longer be paused with any pauseIntent, including assistance and skip, which were accepted before. A review pause also needs a pausedUntilDate from today through the 15th of the due month; a date in the past, accepted before, is now refused. A date that is still today anywhere in the world counts as today. POST /filings/{filing_id}/pause answers a refused pause with 400 and code invalid_request, and POST /filings/bulk/pause still answers 200, listing each refused filing in failed.

When a portfolio credential creates an organization with POST /organizations, the name must now be unique, ignoring letter case. A name already in use answers 409 with code conflict and the message An organization with this name already exists. Before, the 2026-07-21 release accepted any name, including one already in use or one that differed only in letter case, such as acme beside Acme. Creating an organization from a user session without a portfolio is unchanged.

When POST /connections/apideck/{conn_id}/activate finds that the shopId belongs to a connection your organization already has, it reactivates that existing connection, removes the one being activated, and answers 400 as before. The error code is now already_connected instead of invalid_request, with the message This store is already connected. The existing connection was reactivated. The store is connected and nothing more is needed. already_connected is a new value of the code field in error responses.

POST /connections/apideck/{conn_id}/activate accepts three optional fields: netsuiteAccountId and netsuiteSubsidiaryId for a NetSuite connection, and dualentryCompanyId for a DualEntry connection. They are saved in the same step to the connection that remains active, which is your existing connection when the shopId matches one. A field you leave out keeps its saved value, and null or an empty string for dualentryCompanyId covers every company. Other sources ignore these fields.

DELETE /connections/apideck/{conn_id} cleans up a connection left behind when the connect flow was cancelled or failed before activation, and answers 204. It removes only a connection with status INACTIVE or CONNECTION_ERROR that holds no data, and the removal is permanent. An active connection, or one that already holds data such as transactions, is kept and the call answers 409 with code conflict, so it is safe to call even when you did not see how an activation ended. A connection that does not exist or is not yours answers 404, as does a repeat call after a successful delete. A credential for more than one organization must name one with Organization-Id, Connection-Id or Entity-Id, or receives 400.

Two endpoints let an organization that files its own returns record each one in Kintsugi. PUT /filings/{filing_id}/submission takes an action of save_draft, which saves the confirmation details and keeps the filing in FILING, or mark_filed, which saves them and marks the filing FILED. Its optional fields are returnConfirmationId, paymentConfirmationId, amountAdjusted, amountFees, amountPenalties and amountDiscounts, with amounts as decimal strings; a field you leave out is unchanged and a field sent as null is cleared. It returns the updated filing, or 409 when the filing is not in FILING. PUT /filings/{filing_id}/artifacts/{artifact_type} stores the RETURN or PAYMENT confirmation as a PDF of up to 10 MB, sent in the file part of a multipart/form-data body, replacing any document already stored for that type. It answers 409 unless the filing is FILING or FILED, 413 for a larger file and 422 for a file that is not a PDF. Both endpoints are available only for organizations set up to file their own returns, to their Owners and Admins, their API keys and the portfolio that manages them; other callers receive 403.

PUT /registrations/{registration_id}/credentials accepts jurisdictionSpecificFields: cdtfaThirdPartyAccessSecurityCode for a California registration and accessCode for an Idaho registration, named as in the credentials reveal response. Only the keys you send change, and leaving the field out or sending null keeps the saved values. The codes are stored encrypted, are never returned by this endpoint, and can be read back with POST /registrations/{registration_id}/credentials/reveal. An unsupported key or a blank value answers 422. A code for a different state than the registration's answers 400, as does a registration that does not yet have its business name, registration type and sales tax id on file.

With a portfolio credential, POST /organizations accepts two optional fields. billingMode, PARTNER_MANAGED or CLIENT_MANAGED, sets how the new organization is billed; a portfolio that already has a billing type passes it on and the field is ignored, as it is for a test portfolio. businessWebsites lists the organization's websites: an address without a scheme is saved as https, blank entries and duplicates are dropped, and only http and https addresses are accepted. An invalid address or more than 10 unique addresses answers 422. Sending either field from a user session that is not acting for a portfolio also answers 422.

GET /organizations accepts expand=filingMetrics, which adds a filingMetrics object to each organization: totalFilings, filed, pendingApproval (unfiled returns not yet past their due date), overdue (unfiled returns past their due date) and liabilityByCurrency, one { currency, amount } entry per currency. Returns marked do not file are left out of pendingApproval and overdue. Currencies are listed in code order, with returns that have no currency yet last as currency: null, and amounts are decimal strings that are never converted between currencies. An organization with no returns gets zero counts and an empty liabilityByCurrency. Without expand the response is unchanged, an unknown expand value answers 422, and a cursor stays valid with or without expand.

The five endpoints that change addresses now accept the same callers: any member of the organization, a portfolio Owner or Admin who manages it, or an API key for the organization. A portfolio Member now receives 403 with code forbidden from POST /addresses/approve, which accepted them before. The other four, which accepted only the organization's Owner among its own users, now also accept its Admins and Members, who received 403 before. An organization you cannot access still answers 404, and API keys work on all five as before.

On POST /imports/initiate and POST /imports/upload-urls, whether you send userId now depends on your credential. With an API key it is required and must not be blank: a missing userId answers 400 with code invalid_request instead of 422, and an empty or whitespace-only value, accepted before, is now refused the same way. With a signed-in user session, userId is optional and ignored, and the import is recorded under that user.

GET /imports now lists imports by createdAt, newest first, so a new upload appears on the first page. Before, the order did not follow upload time. Paging stays stable while new imports arrive, and a cursor issued before this change answers 400 with code stale_cursor.

GET /transactions/blank-addresses lists transactions that have no address yet, newest first, and GET /transactions/invalid-addresses lists those whose address needs fixing. Both cover committed transactions, including partially and fully refunded ones, dated on or after 2018-01-01, and leave out marketplace transactions. They span every organization you can access, or one when you send Organization-Id, Connection-Id or Entity-Id. Pages use limit (1 to 100, default 50) and cursor, and search matches the transaction id, externalId, externalFriendlyId, description and customer name. The invalid list can also be sorted with sort (usFirst by default, countryAsc or countryDesc) and filtered with country, hasCountry, hasState, hasCity, hasCounty, hasPostalCode and addressNotEmpty, which apply to the invalid addresses themselves; an unsupported country answers 400. A cursor works only with the sort, filters and organization it came from: reusing it with others answers 400 with code stale_cursor.

Transactions now include customerExternalId, your own identifier for the customer, beside customerId and customerName. It is null when the transaction has no customer or the customer has no external id. A list can now show your customer ids without a second call.

POST /reports/jobs accepts an optional deliveryMethod. DOWNLOAD, the default, works as before: fetch the report from GET /reports/jobs/{reportJobId}/download once it is READY. EMAIL sends a download link, when the report is ready, to the email address of the user behind your credential; the request cannot name another address. The response echoes deliveryMethod. EMAIL answers 400 for BULK_FILING_REPORTS, for an organization with email turned off, and for a credential without an email address.

GET /imports/summary returns total, the number of imports across every organization your credential can access, or one organization when you send a selector such as Organization-Id. Archived imports are counted, so total can be higher than the number GET /imports lists.

Editing a transaction address through PUT /addresses/transactions or PATCH /transactions/{transaction_id}/addresses used to reset its unincorporated setting to false, so changing only a street or postal code could apply city tax rates to an address outside city limits. Both endpoints now accept an optional isUnincorporated: true keeps city rates from applying, false clears the setting, and leaving it out or sending null keeps the saved value. A new address created by an edit is saved as false when the field is left out. Changing only this setting on a verified address keeps it verified and recalculates the transaction's tax. Transaction addresses in responses now include isUnincorporated.

A pauseReason is saved in a note on the filing, and the note, including a short label Kintsugi adds, holds up to 500 characters. A longer reason used to fail with a server error, sometimes after the filing was already paused. It now answers 400 with code invalid_request before anything changes, and POST /filings/bulk/pause refuses the whole request.

Three v1 endpoints, now documented, let you ask Kintsugi to file returns for periods before your regular filing schedule began. GET /v1/filings/back-filing-request/options lists each active US registration with the periods it can request: periods that have ended, start on or after the registration's tax collection start, end before its first regular filing period, and are not already covered by a filing. Each period has a start_date, an end_date and a label, and each registration a remittance_tag (Paid with return, State bills you later or null) saying how the state collects penalties and interest. POST /v1/filings/back-filing-request takes requests, each a registration_id with its periods, and optional notes. It creates one BACK_FILING filing with status UNFILED per period and returns them in created_filings, with their count in total_created, and 200. Every period is checked before anything is created, so one invalid period refuses the whole request with 400. An unknown registration_id answers 404, an organization without a payment method on file receives 402, and an organization without back filing available receives 404 from both request endpoints. Nothing is filed until each filing is approved with the current terms from GET /v1/filings/back-filing-terms/current, which returns their id, version and text.

A new exemption type, partial, records a customer's California partial exemption certificate, such as the one for qualifying manufacturing and research equipment. Unlike a full exemption, a sale to that customer stays taxable: Kintsugi applies the reduced rate the certificate allows to qualifying items sold in California. Create one with exemption_type partial and a certificate_type on POST /v1/exemptions, or with exemptionType and certificateType on POST /exemptions and POST /exemptions/bulk in the 2026-07-21 release. The certificate type is the form's code from GET /v1/exemptions/partial-certificate-types, which lists each form's code, name, jurisdiction and country; its optional jurisdiction parameter narrows the list to one state, ignoring case. Today the list holds nine California forms. A partial exemption needs country US and jurisdiction CA, and the certificate type is accepted only on a partial exemption. Exemptions, including those embedded in transactions, now report the certificate type, which is null for every other type. Partial exemptions are available to organizations that have them enabled; for any other organization, creating one answers 400.

Deregistering now records when and why the registration closes. POST /v1/registrations/{registration_id}/deregister requires a JSON body with closure_date, reason and final_return_acknowledged, so a request with no body, which succeeded before, is now rejected with 422. The 2026-07-21 release changed the same way, with the fields closureDate, reason and finalReturnAcknowledged.

Creating a credit note with an external_id already used for a credit note on the same original transaction used to fail with 409 Conflict. It now succeeds and returns the stored credit note unchanged. On v1 that response is 200, and creating a new credit note now answers 201 instead of 200. On the 2026-07-21 release the stored credit note comes back with 202, the same as a new one. The same external_id against a different original transaction still returns 409.

Creating a physical nexus for an organization, country, state and category that already has one used to fail with 409 Conflict. It now succeeds and returns the stored record unchanged: the dates and address in the request are not applied. On v1 and the Partner API the response is 200, the same as for a new record. On the 2026-07-21 release it is 200 for an existing record and 201 for a new one.

Creating a product with an external_id and source that already exist used to fail with 409 Conflict. It now succeeds with 200 and returns the stored product unchanged: the fields in the request are not applied. A product you deleted is restored instead, with status PENDING, and is not used in tax calculation until it is approved again. Creating a new product now answers 201 instead of 200.