ReliefWeb field searches need query-to-result lineage

Record the field that the request actually searched

ReliefWeb's official fields tables distinguish content types and identify field names, data types, abbreviations, and whether a field supports queries, filters, sorts, facets, an exact qualifier, or multiple returned values. An integration should preserve the endpoint, content type, request field path, common or exact qualifier, operator, value, filter structure, sort, facet, result-field selection, page controls, and retrieval time. A user-facing phrase such as searched country is too imprecise when the request actually targeted a default subfield or a broad common representation.

Store the API documentation or schema version used by the integration and the application's own mapping version. Field capabilities are not interchangeable: a field may be searchable but not sortable, facetable but multi-valued, or available for only some content types. Reject or flag an unsupported combination before the application silently substitutes a different path. This article governs field and search semantics; it does not repeat the prior ReliefWeb list-versus-item capture decision, disaster-to-supplier exposure matching, or an operational risk conclusion.

Separate the matched representation from the returned object

The documentation gives a specific warning: querying a parent field such as country can default the search to country.name, while the result returns country objects rather than only the names. Preserve the field that matched, the returned object path, identifier, name, code or other available attributes, primary indicator where present, and the parent record identity. Do not flatten the object to the matched label and then reconstruct identity from text later.

That distinction matters when two records share a label, a name changes, one object has several representations, or a returned array contains several values. Keep match evidence separate from entity selection. A search for a name can identify candidate records; downstream logic should use the returned stable identifiers and declared relationship fields where the API supplies them. If the result omits the identifier or required attribute, retain the gap rather than treating the label as an authoritative key.

Make common and exact searches explainable

ReliefWeb says common fields can combine representations—for example, a source.common field containing both full and short source names—and that common fields often have an exact version. Those conveniences should be visible in the evidence. Record whether a hit arose through the long name, short name, exact term, tokenized text, or another documented representation. The application may rank or group candidates, but it should not tell an operator that the publisher or location was exactly matched when the request used a broader common field.

A reviewable rule specifies why common or exact behavior was selected, how case, punctuation, aliases, codes, missing values, arrays, and renamed entities are handled, and which result states require human review. Test false positives and false negatives deliberately. Search expansion can improve recall while degrading identity precision; exact search can improve precision while missing legitimate alternate forms. Both outcomes need counts, examples, and exception handling before the search becomes part of a supply decision.

Replay the same signal through semantic changes

A useful integration test queries reports and disasters using a parent field, a named subfield, a common field, and an exact field. Include one object with a short and long name, a multi-valued field, a label collision, a renamed object, a missing optional attribute, pagination, and a changed mapping version. Reviewers should reproduce why each record appeared, which returned object was selected, which identifier entered the downstream record, and what changed when the query path changed.

Supply Chain Signal reviewed the registered ReliefWeb API fields tables on September 20, 2026. The source supports the documented content-type tables, field attributes, advanced-search abbreviations, common and exact behavior, parent-field search default, and nested JSON-result distinction. It does not establish API availability for a particular run, source-record completeness, disaster severity, supplier identity, location match, exposure, disruption, commercial impact, or response. No attributable semantic update after the September 17 cutoff was established; this is durable current-documentation analysis.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Supply Chain Signal will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.