Findings — where documentation and file disagree

The collection description tells a new developer to authenticate using an Authentication folder and collection-level authorization. Neither exists in the file. There is no auth block, no pre-request script, no Authentication folder, and the only defined collection variable is baseUrl — clientId and clientSecret are referenced but never defined.

A developer following the Quick Start verbatim cannot authenticate: every one of the 14 requests would return 401 Unauthorized.

This claim is re-verified automatically at every ingest — see check G1 on the methodology page. If a corrected collection is ever shipped, this finding's evidence table updates itself.

The gap is recoverable, because the real OAuth 2.0 configuration lives in the public Onboarding Guide (see Lesson 1):

Note that auth.app.iwave.com is a different host from the API's api.app.iwave.com — and the collection defines no variable for it.

The 28 saved response examples were generated from the schema's types without semantic constraints. Audited automatically at every ingest (see methodology, checks G2a–G2c):

• 16 of 28 capacityRangeLow/capacityRangeHigh pairs are inverted — e.g. low=8967, high=219.
• All 12 age values are humanly impossible (4012, 7722, 9631…).
• List Projects shows totalRows: 6141, validRows: 7799 — more valid rows than rows.

What this means for you: the examples are authoritative for structure (field names, nesting, types, status codes) and useless for meaning. This site therefore labels every displayed value as either Tier A — source-verbatim or Tier B — authored illustration, and never mixes them silently.

One real signal survives the noise: every score field observed (capacityScore, affinityScore, propensityScore, rfmScore, …) falls in 0–4 across all 28 examples. That consistency across otherwise random data almost certainly reflects a genuine schema bound. It is, however, an inference — the only one this site makes — and is labelled as such wherever it appears (audit check INF1).

Step 2 of the bulk lifecycle says CSV upload is supported and points the reader at "the text/csv schema" for column headings. That schema is not in the collection: no request declares a text/csv content type, and no CSV example exists anywhere in the file.

Practical consequence: you cannot determine the column headings from the collection alone. Until confirmed, use the JSON array form of Step 2 — its schema is fully specified by the request body example. The authoritative OpenAPI specification likely resolves this (internal corroboration: INT-03).

Step 1's optional scoreConfiguration block takes affinity codes: the example shows "primaryAffinity": "DIS" described as "Science" and "secondaryAffinity": "AGR" described as "Human Services - Basic/Emergency Aid". Two codes of an unknown-size vocabulary; no list exists anywhere in the collection, and the codes are not mnemonic.

Mitigating: the collection itself recommends omitting the block, so most integrations never need the vocabulary.

The profile response's additionalData.donations object contains 29 named sector fields (arts, educationHigher, science…). Whether those correspond to the affinity vocabulary is unverified — a plausible hypothesis this site deliberately does not state as fact.

List Profiles takes page and itemsPerPage. The other four array-returning endpoints — List Projects, Step 5: Retrieve Scored Profiles, its deprecated alternate, and Step 6: Retrieve Project Errors — take no pagination parameters at all.

Step 1 advertises projects of up to 1,000,000 records. An unpaginated GET /project/:id/profiles over such a project implies an enormous single response. Whether pagination is undocumented-but-supported or genuinely absent cannot be determined from the collection — this site flags it as an open question rather than asserting either way.

Also unstated: any maximum for itemsPerPage (both query parameters carry null descriptions in the file).

The 4xx examples use two distinct shapes:

RFC 7807-style (profile 404, score-request 404, project status/process 404):

{ "title": "An error occured", "detail": "", "status": "404", "type": "/errors/404" }

(typo "occured" is in the source; status is a string)

Simple code/message (profile 400, Steps 2/3/6 404):

{ "code": 404, "message": "" }

(code is an integer)

Worse, within Create Screening Project alone the 400 example carries "status": 400 as an integer while the sibling 404 carries "status": "404" as a string.

Lesson: never bind a single error model. Parse defensively — try both shapes, and treat the numeric field as either string or int.