A tender link record is a dated identity and recovery package, not a copied browser address. It names the publishing authority and portal, the procurement procedure, notice publication and version, relevant lot, buyer reference, public landing page, machine-readable representation when one exists, and an independently tested recovery route. public_locator_verified means a documented or publisher-declared public URL resolves without a prior session and returns the expected notice. public_recovery_verified means no dependable detail URL is available, but a fresh user can recover the notice from a public search using recorded identifiers. authenticated_route_only keeps the existence and purpose of a restricted route without sharing its URL or credentials. temporary_locator_rejected marks a session-bound, signed or expiring address that must not be published. identity_mismatch, source_conflict and source_unavailable prevent reuse when the destination is wrong, contradictory or untestable. superseded links to the replacement record. A working link does not prove that the tender is current, open or unchanged.
A link copied from a procurement portal can work perfectly for the person who copied it and fail for everyone else. The address may contain a session identifier, a one-time ticket, a signed download signature, a result-list position or a route that depends on cookies already present in the browser. Some portals return a login page with HTTP status 200, so a simple uptime check reports success even though the notice is gone. Others redirect old records to a generic search screen. A public notice URL may remain available while the tender documents sit behind a different operational portal. Saving only the address loses identity; saving the whole authenticated address can disclose access. The recovery record must survive both failures.
Preserve the procurement identity independently from every locator. Use identifiers exactly as the publisher defines them and keep their scopes distinct: a procedure identifier groups procurement events, a notice identifier identifies a notice lineage, a version identifies an edition, a publication number addresses a published representation, and a lot identifier narrows the object. Prefer a direct route documented by the publisher, then a declared canonical link, then a fresh public recovery path. Test from a clean anonymous context and assert the returned identifier, buyer and notice type, not merely the status code. Never publish a URL that carries an authentication, session or signed-download value. An agent may inspect public metadata, follow safe retrieval routes and report a bounded state. It must not log in, accept portal terms, reuse another person’s cookies, download restricted files or contact the buyer without separate authority.
Direct answer
Save the notice identity and a tested route back to it
A reusable tender link needs two independent parts. The first identifies the procurement object: publisher, procedure, notice, version and lot. The second explains how to retrieve the publisher’s representation of that object. If the route stops working, the identifiers support recovery. If the route resolves to the wrong record, the identity checks expose the mistake. A bookmark alone provides neither safeguard.
The address bar is evidence of one navigation event. It is not a promise from the portal. A search application can encode filter state, page number and selected row in the query or fragment. A document service can issue a short-lived signed address. An authenticated portal can place a session value in the path or query. Each address may be syntactically valid under RFC 3986 while remaining unsuitable for publication or later reuse.
Test the candidate public link in a browser profile or HTTP client with no portal cookies. A successful test checks content, not just transport. Confirm the official notice identifier or publication number, buyer, notice type and, where relevant, lot. Record a login page, generic homepage, bot challenge or language selector as the page received. Do not reinterpret it as the tender because the server returned 200.
Link stability and tender currency are separate. A direct link can reliably return the original notice for years while a later change notice has altered a deadline or cancelled a lot. Preserve the stable publication and then run the amendment and open-status checks. Rewriting the old link to a latest view would erase the evidence you originally cited.
| State | Minimum evidence | Permitted use |
|---|---|---|
| public_locator_verified | Fresh anonymous retrieval and identity match | Share with its checked time and scope |
| public_recovery_verified | Identifier search reproduces the intended result | Share portal entry and recovery recipe |
| authenticated_route_only | Official instructions require an account | Share the purpose, not a captured private URL |
| temporary_locator_rejected | Session, signature, ticket or expiry is present or suspected | Discard from shared output and find a public route |
| identity_mismatch | Returned record fails an identity assertion | Stop reuse and investigate |
| source_unavailable | Public test cannot reach or assess the source | Retry later without claiming a broken notice |
Identifier layers
One procurement can carry several correct identifiers
TED eForms makes the distinction explicit. BT-04 identifies the procurement procedure. BT-701 identifies one notice and is a version 4 UUID. BT-757 identifies the notice version. The Publications Office adds OPP-010, the notice publication number, when it publishes the notice. A change notice receives its own notice identifier and refers to the notice and version it changes. Saving only one of these fields answers only one layer of the identity problem.
TED also documents a direct public URL pattern based on language, publication number and representation format. HTML, PDF, signed PDF and XML can therefore have predictable routes without copying a search session. The publication number addresses a published notice representation; the procedure UUID groups related procurement events. Preserve both. Later research can recover the cited publication and still find related notices in the procedure.
Contracts Finder uses another scheme. Its official API documentation says a published notice is retrieved by an internally assigned GUID that uniquely identifies that notice. A buyer may also provide its own reference. The GUID supports the Contracts Finder retrieval; the buyer reference helps a human match tender documents and correspondence. Neither should be relabelled as the other.
OCDS adds a useful cross-publisher distinction. An OCID identifies the contracting process across releases, while a release ID identifies one publication event within that process. The standard encourages a persistent URL for each release and record. A compiled record is convenient for the latest known values, but it is not a substitute for the immutable release cited in an earlier decision.
| Identifier | Scope | Use in recovery |
|---|---|---|
| Procedure ID | Contracting process | Find related planning, competition and result notices |
| Notice ID | Notice lineage | Distinguish this notice from other procedure events |
| Notice version | Edition of that notice | Prove which editorial version was checked |
| Publication number | Published representation | Build or verify a publisher-supported direct route |
| Lot ID | Part of the procurement | Confirm the retrieved notice contains the cited object |
| Buyer reference | Buyer or portal namespace | Match operational documents without assuming global uniqueness |
| OCID and release ID | Process and publication event | Join open data while preserving publication history |
Security boundary
A query string is not automatically unsafe, but a secret is
RFC 3986 defines a query as part of a URI and allows it to carry identifying data. A public BOAMP route that searches for an official "idweb" value can be a legitimate reusable locator. Removing every query string would break valid publisher routes. Safety requires knowledge of the publisher contract and the parameter’s role, not a rule that everything after a question mark is disposable.
RFC 6596 defines the canonical link relation as the author’s preferred IRI among duplicate representations and gives session-parameter pages as a common use case. Treat a declared canonical target as strong route evidence after checking that the target contains the same notice. The RFC warns that a canonical declaration can be inaccurate or malicious. It is a relationship supplied by the publisher, not independent proof of identity.
OWASP explains why session values must not travel with a shared link. A session identifier in a URL can appear in browser history, bookmarks, logs, referrer headers and search indexes. In an authenticated portal, the token can be temporarily equivalent to the user’s authentication. Do not store the original value in a public error report and do not test whether another person can replay it.
Use an allowlist of publisher-documented public route patterns. If a captured address falls outside it, preserve only non-secret diagnostics, such as the host, path shape, parameter names, checked time and the fact that a restricted value was present. Then recover the notice through its identifier. Deleting a suspicious parameter from the captured address does not create an approved public URL unless the publisher documents the resulting route.
| Observed address | Record treatment | Reason |
|---|---|---|
| Publisher-documented notice route | Test and retain | The route contract is public |
| Declared canonical target | Verify content, then retain | Preferred duplicate can remove session state |
| Public identifier query | Retain if documented and tested | A query can legitimately identify the record |
| URL containing a session or bearer value | Do not publish or replay | The value can grant or expose access |
| Signed document URL with expiry | Reject as a stable locator | It addresses temporary delivery, not durable identity |
| Redirect to login or generic search | Fail the identity assertion | Transport success does not recover the notice |
| Browser fragment selecting an app row | Use only with documented semantics | The server may never receive or preserve it |
Recovery contract
The fallback must work without the original browser
When no durable detail page exists, write a reproducible public search recipe. Name the portal home or notice-search endpoint, the exact field label, the identifier and any required year or notice family. State the expected buyer, notice type, title fragment and lot. A recipe that says “search the portal” is too weak. A recipe that depends on the original user’s saved list is not public recovery.
Record each representation separately. The statutory publication may offer stable HTML or XML while the designated procurement portal controls documents, clarifications and submission. The public record can cite the notice route and describe how an authorized user reaches the operational portal. It must not copy an account-bound route from inside that portal. This separation keeps public provenance useful without flattening access controls.
For HTTP testing, retain the initial URL, status sequence, redirect targets, final URL, content type and a small set of identity assertions. RFC 9110 distinguishes permanent redirects from temporary redirects, but the status code alone does not establish that the new resource is the same notice. Compare the identifiers after every redirect. If the portal blocks automated traffic, report source_unavailable and provide a manual public check. A bot challenge is not a confirmed broken link.
A screenshot, PDF or local HTML capture can document what was observed at a particular time. It is supporting evidence, not the canonical live source. Store a retrieval time and cryptographic digest where policy permits, plus the original publisher identity. Never present the capture as current after an amendment. Its value is to explain what an earlier decision relied upon when the live representation later changes or disappears.
| Field | Required content | Failure prevented |
|---|---|---|
| source | Publisher, portal role and jurisdiction | Mistaking a host for the issuing authority |
| object | Procedure, notice, version and lot identifiers with schemes | Collapsing identity scopes |
| public_locator | URL, basis, representation and checked time | Sharing an untested bookmark |
| retrieval_observation | Status, redirects, final host, media type and assertions | Accepting a login page as success |
| recovery_recipe | Entry point, field, value and expected result | Losing the notice after route change |
| access_boundary | Public, authenticated, restricted or untested | Crossing permission boundaries |
| lineage | Changed, replacement and related publication references | Treating the stable publication as current |
| state | Decision, reason, recheck trigger and superseding record | Silent reuse after evidence changes |
Worked example
Recover a TED notice after an operational portal session expires
Consider a fictional services procurement found through an aggregator. The aggregator opens TED, which sends the user to the buyer’s procurement portal. After login, the address bar contains a session route to a document list. The researcher pastes that address into a shared opportunity note. The next morning it redirects a colleague to the login page. The saved note has a title and deadline, but no publication number or procedure identifier.
The repair begins at the public TED representation. The researcher records the publication number shown by TED, the eForms notice UUID and version, the procedure UUID, buyer, notice type and lot. TED’s published direct-link pattern supplies separate HTML and XML routes for that publication number. Both are tested anonymously and must return the recorded identifiers. The link record now preserves a human-readable citation and a machine-readable recovery route.
The buyer portal remains necessary for the current documents and eventual response. Its public landing or search page is recorded with the buyer reference and an identifier-based recovery recipe. The expired session address is removed from the shared note without being logged elsewhere. The access field says authenticated_route_only for the document workspace. An authorized submission owner can enter through the public portal and authenticate under the organization’s normal process.
The result does not say that the documents are complete, the deadline is current or the procurement remains open. Those claims need their own checks against the latest notice and portal material. The stable-link record guarantees a narrower result: another reviewer can recover the same cited publication, recognize the operational route and see exactly where authentication begins.
| Before | After | Boundary |
|---|---|---|
| Title and expired session URL | TED publication number plus notice and procedure IDs | Identity no longer depends on cookies |
| One browser address | Tested public HTML and XML representations | Each route has its own retrieval evidence |
| No way back to buyer portal | Public entry point, buyer reference and recovery recipe | Login occurs only for an authorized user |
| Assumed current record | Cited publication plus separate lineage recheck | Stable does not mean latest |
| Shared access-bearing address | authenticated_route_only state | No token or session value leaves its context |
What good looks like
Useful outcomes from stable tender link
- The record distinguishes the procurement procedure, the notice publication, its version and the relevant lot instead of treating one URL as their shared identity.
- A fresh anonymous retrieval proves that the public destination returns the intended notice rather than a login page, generic search screen or unrelated record.
- Session identifiers, authorization codes, signed download values and other restricted locators stay out of shared records, logs and public pages.
- A documented identifier-based search path remains available when the portal offers no dependable detail URL.
- Human-readable HTML and machine-readable XML, JSON or API routes are recorded as separate representations with their own checks.
- Redirects and portal migrations preserve an observed chain without silently replacing the original publisher identity.
- Notice currency, amendment lineage, document access and submission routes remain separate verification tasks.
- Another person or agent can repeat the recovery test from the fields in the record alone.
Operating model
How to run the work
- 01
Fix the object being referenced
Record the jurisdiction, official publisher, portal role, buyer, procedure, notice type, publication, version and lot. Keep the title as a check value, not as the primary key.
- 02
Collect identifiers at their stated scopes
Capture each identifier with its scheme, label, source field and scope. Do not compare a buyer reference, procedure UUID and publication number as though they were interchangeable.
- 03
Prefer a publisher-supported public route
Use the route pattern documented by the official publisher or a canonical link declared by the returned representation. Record why the route was selected.
- 04
Reject restricted URL material
Inspect the scheme, host, path, query parameter names and fragment locally. If the address contains or may contain a session, bearer value, signed token or private object reference, do not copy it into the record.
- 05
Run a clean retrieval test
Open the candidate route without prior portal cookies or authentication. Record the checked time, response status, redirect chain, final host, content type and the identity assertions found in the response.
- 06
Write a fallback recovery recipe
Name the public portal entry point, exact search field, identifier to enter, expected result and identity checks. The recipe should not depend on a saved search or account.
- 07
Separate representations and permissions
Record notice HTML, notice data, document access and submission as different routes. State which are public, which require an authorized account and which were not tested.
- 08
Set recheck triggers
Revalidate after a redirect change, portal migration, amendment, replacement notice, certificate error, identity mismatch or planned external publication of the link.
Evaluation
Questions that change the decision
- What exact procedure, notice publication, version and lot must the reference recover?
- Which organization publishes the notice, and which portal only hosts documents or submission?
- Which identifier is globally unique, and which is unique only inside a buyer, portal or notice?
- Does the publisher document a direct route or expose a canonical link for this representation?
- Does any path, query or fragment value appear to carry session state, authorization or expiry?
- Can an anonymous client recover the record and verify its identifier, buyer and notice type?
- Does the destination represent the cited publication or a compiled current view that may have changed?
- What public search recipe works if the detail route disappears?
Failure modes
Where teams lose control
A team can share a session URL that exposes a live credential or binds the recipient to the wrong user context.
An HTTP 200 response can be accepted even when it contains a login form, consent screen or empty application shell.
A portal redirect can land on a search homepage and be recorded as successful because the host still responds.
A notice publication number can be confused with a procedure identifier, causing later amendments or awards to disappear from the lineage.
A canonical link can be trusted without checking that its content actually contains the same notice.
A document signature or temporary object-storage link can be shared as though it were the public notice landing page.
An archived local copy can be presented as the current official source after the publisher has issued a correction.
An agent can cross an access boundary by signing in, replaying cookies or accepting terms merely to make a broken link work.
Measurement
Measure the finished job
Measure the completed workflow, including review effort and exceptions. Output volume on its own is not evidence of a better process.
- link records containing one publisher, scoped identifiers, a public route or recovery recipe and a checked instant
- anonymous retrievals that match expected notice identifier, buyer and notice type
- shared URLs with no session, authorization, signature or expiry values
- fallback recoveries completed without a saved search, cookie or account
- HTML, data, document and submission routes typed separately
- redirect changes recorded with previous and final hosts instead of silently overwritten
- identity mismatches and unavailable sources that stop dependent automation
- rechecks completed after portal, notice-version or publication changes
Questions
Common questions
Can I copy the tender URL from my browser address bar?
Only after identifying the publisher-supported public route and testing it without your cookies. An address produced inside a login or search session is not safe by default.
Should every query string be removed?
No. Some official public routes use a query to carry the notice identifier. Retain only publisher-documented, tested parameters and never publish session, authorization, signature or expiry values.
Does a canonical link prove that the URL is correct?
It is strong publisher-supplied evidence of the preferred duplicate. Verify that the target returns the same notice identifiers because canonical declarations can be wrong.
Is HTTP status 200 enough for a link check?
No. Portals often return login, consent and generic search pages with status 200. Match the notice identifier, buyer and notice type inside the response.
What if the notice is visible only after login?
Record its public identity and the authorized entry route. Mark the workspace authenticated_route_only. Do not share the captured private URL or use another person’s session.
Can a PDF download be the stable link?
Yes when the publisher documents a durable public PDF route, such as a route based on a publication number. A signed or expiring object-storage URL is temporary and should not be used.
Does a stable notice link prove the tender is still open?
No. The link can faithfully return an old publication. Check later amendments, cancellation, current documents and the applicable response deadline separately.
What should an agent return when a portal blocks automated access?
Return source_unavailable with the checked time, public identifier, attempted route and a safe manual recovery recipe. Do not label the notice broken from a bot challenge alone.
Sources
Primary references
- TED direct notice links and public Search API Publications Office of the European Union
- TED eForms notice, version and procedure identifiers Publications Office of the European Union
- Contracts Finder API documentation UK Cabinet Office
- OCDS identifiers Open Contracting Partnership
- OCDS releases and records Open Contracting Partnership
- Session identifiers in URLs OWASP Foundation
- RFC 3986 URI generic syntax RFC Editor
- RFC 6596 canonical link relation RFC Editor
- RFC 9110 HTTP semantics and redirects RFC Editor
About the author
Tony Kim
Tony writes about applied AI, dependable product engineering and the systems that turn complex response work into controlled delivery.
Zelius
Managed tender intelligence and bid execution for teams that want the commercial outcome.
Suppliers, founders and commercial teams pursuing public or private opportunities. Start with the workflow, constraints and evidence you already have.