Changelog

Opportunity list: one entry per tender

September 2026

The same tender is often published on more than one of the sources Prokure watches. Prokure already grouped duplicate listings so only one appeared in the digest, but the Opportunities list showed every copy, so one tender could appear more than once. The list now applies the same grouping: the portal’s Opportunities page and GET /api/v1/opportunities leave out a listing grouped under another copy of the same tender, under every filter, sort, status, archive view and page.

Grouped copies are not deleted. GET /api/v1/opportunities/{id} still returns one by its id, so existing links to it, including those in older digest emails, keep working.

Grouping also catches more duplicates than before. Listings are grouped when they share a solicitation number within the same buyer, or when their title, buyer and closing date match. The title comparison ignores letter case, punctuation, accents, HTML entities such as &, and a municipal prefix such as “City of” on the buyer’s name, so copies that differ only in those respects are still grouped. A matching title does not group two listings that carry different solicitation numbers. The listing from the tender’s originating source is preferred over a republished copy.

The response schema, query parameters, scopes and rate limits are unchanged.

See Duplicate listings and Why an opportunity isn’t in your list.

Browser sessions: a higher exchange limit

September 2026

POST /api/v1/session now allows 30 requests per 60 seconds, up from 10, because that limit is counted per client IP: everyone signed in behind one office egress address drew on a single budget, and each open portal tab renews its own session. The portal also no longer repeats an exchange it has already made.

Ask Prok about an opportunity

September 2026

Prok can now answer questions about one solicitation, from what it already holds on that notice:

• POST /api/v1/opportunities/{id}/ask: a question of 1–1000 characters and, optionally, the conversation so far as history — up to 10 turns, oldest first, alternating user and assistant and starting with a user turn. The response is a plain-text answer and the model that composed it. Requires opportunities:read, and allows 20 requests per 60 seconds.

The answer is grounded in the notice’s facts and description, an excerpt of the solicitation document when one was retrieved, Prok’s extraction, Prok’s verdict, the matched product, and your company profile — and nothing else. When the answer is not in that material Prok says so instead of filling the gap. Only the most recent six turns of history reach the model, and a history in any other order is refused with 400 validation_failed.

See Asking Prok about an opportunity.

Opportunity list carries the verdict rationale

September 2026

GET /api/v1/opportunities list items gained seven fields, so a list view can show why a match scored the way it did without a detail request per opportunity. All seven are nullable:

• explanation — Prok’s written reasoning for the verdict, the same text the detail record carries.
• summary — Prok’s plain-language account of what the notice is procuring.
• source_url — the posting itself.
• notice_type and solicitation_number — as published on the notice.
• latest_feedback_action and latest_feedback_at — the newest feedback action recorded for that opportunity on your account, and when.

Nothing moved: the sub-scores and the extracted signals are still only on GET /api/v1/opportunities/{id}.

The portal’s Opportunities page is rebuilt on those fields. It opens with This week’s results — matches discovered in the last 7 days, best score first — and renders matches as cards carrying the reasoning, each with Relevant, Not relevant and Archive controls and an Ask AI button that opens the assistant described above. The table view remains, behind a Cards/Table toggle, and the portal has gained a light/dark toggle.

See Understanding match scores and Sending match feedback.

Product catalog: CSV import

September 2026

A catalog can now be loaded from a spreadsheet instead of one product at a time, from the Product catalog page’s new Import button or over the API:

• POST /api/v1/products/import: a multipart/form-data upload of one .csv of at most 2 MB and 500 data rows, with the columns oem_partner, name, model, description, commodity_codes, rep_status and source_url. Requires profile:write. ?dry_run=true validates the file and reports what it would create and update without writing anything.
• GET /api/v1/products/import/template: the header row plus one example row as text/csv. Requires profile:read.

Validation is all or nothing. A missing, unknown or repeated header column, any invalid cell, a partner, name and model repeated on two rows, or more than 500 rows refuses the whole file with the new 422 invalid_import, whose issues list carries the row, the column and the problem for the first 50 and whose issue_count gives the true total. Nothing is written on a refusal.

A successful import writes partners and products in one transaction. Products are matched on partner, name and model, so a re-import updates rather than duplicates. The file is authoritative for every column it carries, blank cells included, while specs and status are preserved because the file cannot carry them: a discontinued product stays discontinued. New partner names are created and added to manufacturer_partners on the company profile through the change history with source portal_import, and a partner previously removed from the profile is re-authorized and added back. The same transaction records the background indexing the imported products need and one re-score for the change: success does not mean indexing has finished, and the products count toward matching once it does.

See Importing products from CSV.

Product catalog

September 2026

The manufacturer partners and products Prok matches solicitations against are now yours to manage, in a new Product catalog page under Settings and over the API:

• GET /api/v1/products: the catalog, newest first, filterable by status, partner_id and a free-text q over name, model and description, paged with an opaque next_cursor. Requires profile:read.
• GET /api/v1/products/partners: every manufacturer partner with its active and discontinued product counts. Requires profile:read.
• POST /api/v1/products/partners: add a partner. Requires profile:write. The name is also added to manufacturer_partners on the company profile through the change history with source portal_edit, so it is revertible like any other profile change. Re-posting a name already on file re-authorizes it; it does not reactivate that partner’s discontinued products.
• POST /api/v1/products: add a product under a partner, with rep_status carried or catalog. Requires profile:write. A partner that is not yours returns 404.
• PATCH /api/v1/products/{id}: change any subset of a product’s fields, plus status. Requires profile:write.

Two new error codes come with them, both 409. already_exists refuses a product whose partner, name and model duplicate one you already have, on create and on a rename alike. partner_not_authorized refuses a catalog write against a manufacturer partner you have removed from your company profile; posting the name to POST /api/v1/products/partners re-authorizes it, and the write then succeeds.

Products are never deleted. Discontinuing one takes it out of matching and keeps the record; setting status back to active brings it back. Any catalog change that can move a score queues a background re-score whose results reach your next digest, the same way a profile edit does.

See Product catalog.

Company profile: editing

September 2026

The company profile is now editable directly, rather than only through what Prok picks up from your replies and feedback. The portal’s Company Profile page has an Edit control on each card, and one new endpoint does the same thing over the API:

• PATCH /api/v1/profile: apply between 1 and 50 operations in one request, add/remove on the list fields (categories, geography, certifications, exclusions, manufacturer partners, target buyers) and set on overview, business role, Canadian-supplier status, employee count, and the contract value bounds. Requires profile:write. The response returns the updated profile, the changes that applied, and the operations that were skipped with a reason code for each (already_present, not_present, already_set, min_exceeds_max, invalid_value, error). A skipped operation is not an error: the rest of the batch still applies.

employee_count is a new profile field, editable the same way and returned by GET /api/v1/profile. Edits are recorded in the change history with source portal_edit and are revertible on the usual terms, and removing a manufacturer partner still deactivates that partner’s catalog products. Identity fields (legal name, business number, CAGE code) remain unchangeable through the API.

See Editing your company profile.

Context documents: refresh failures no longer take a document offline

September 2026

A context document that was already indexed keeps serving its last successfully processed version if a later background refresh fails. The failure is reported in ingest_error while status stays ready, and the note clears on the next refresh that completes. Previously a failed refresh flipped the document to failed even though its content was still in use.

Company profile: history and revert

August 2026

Prok now edits your company profile directly from what you tell it — an email reply or portal feedback that states a durable fact (“we don’t work with Vertex anymore,” “we just got ISO 9001”) is applied automatically, up to 10 field changes per message. Three new endpoints make that visible and reversible:

• GET /api/v1/profile — the profile as it stands now. Requires profile:read.
• GET /api/v1/profile/changes — every change, newest first, with its before/after values, source, and whether it can still be reverted. Requires profile:read.
• POST /api/v1/profile/changes/{id}/revert — revert one change. Only the latest change to a field qualifies; an older or already-reverted one returns 409 (superseded or already_reverted). Requires profile:write.

Removing a manufacturer partner now deactivates that partner’s catalog products as part of the same change, reported in each entry’s cascade_summary; reverting the removal reactivates them. Any email confirmation that changed the profile ends with Reply "undo" to revert these profile changes. — replying does exactly that, threaded to the original message.

See Company profile.

Context documents and learned rules

August 2026

Two additions to company settings:

• Context documents — upload PDF, DOCX, TXT, or MD files (up to 15 MB, 50 per account) that Prokure draws on for both proposal drafting and match scoring. POST/GET/DELETE /api/v1/knowledge/docs. Requires profile:write to upload or delete, profile:read to list.
• Learned rules — read the durable policies Prokure has learned from your feedback, with provenance back to the opportunity that produced each one when known, and deactivate or reactivate them. GET/PATCH /api/v1/settings/rules. Requires settings:read or settings:write.

Disagreeing with a match in the portal (POST /api/v1/opportunities/{id}/feedback with "verdict": "disagree") now always re-evaluates that opportunity from scratch, rather than potentially reusing an existing verdict.

See Context documents and Learned rules.

Notification settings

August 2026

Two new endpoints let a tenant read and change how Prokure emails them:

• GET /api/v1/settings/notifications — digest days, hour and time zone, minimum score, maximum items, recipients, and the amendment-alert policy, plus the computed next send time. Requires settings:read.
• PATCH /api/v1/settings/notifications — update any subset of those fields. Requires settings:write. Every change is recorded in the account’s audit trail.

See Digest and notification settings.

v1: initial public API

August 2026

The first publicly documented version of the Prokure API, served from https://app.prokure.ca. Authentication is a pk_live_ API key in an Authorization: Bearer header, scoped by the six portal scopes.

Endpoint groups in this release:

• Opportunities: list and read matched solicitations with their scoring rationale, archive and unarchive them, and submit feedback on a verdict.
• Profile: read the identity and company behind the current credential (/api/v1/me).
• API keys: list, create, and revoke keys from a signed-in portal session.
• Session: exchange a portal token for a session cookie, and sign out.
• Scopes: the public scope vocabulary, readable without a credential.

See the API reference for the full generated specification.