For technical administrators

<!-- order: 7 | Your clients, products, verifications, facilities, certificates and shared opportunities: what you can read and how. -->

Your TA's key reads everything your TA works on: clients, brands, products and their packages, verifications with their facilities and history, facilities, certificates, certificate PDFs, and the opportunities shared with you. It never sees another TA's records. When a product moves to your TA, you see its past cycles too, read only.

Your key needs verification.read for most of this, certificate.issue for certificate PDFs and prospect.read for opportunities. Your organization's admin sets a key's scopes on the Keys and tokens page.

Check whether a product exists

curl -H "Authorization: Bearer $TOKEN" https://api.foodintegrityproject.org/v2/products/2-12345-00001

A product that isn't yours, or doesn't exist, answers 404 with the code not_found (v1 answered 400). The product comes with its categories, other certifications, a count of packages and each program's current verification.

Keep up with changes

Every list takes updated_since and pages with cursor:

# Verifications changed since yesterday, the latest cycle of each product only
curl -H "Authorization: Bearer $TOKEN" \
  "https://api.foodintegrityproject.org/v2/verifications?current=true&updated_since=2026-11-10T00:00:00Z"
# Newly approved clients (was GET /application)
curl -H "Authorization: Bearer $TOKEN" \
  "https://api.foodintegrityproject.org/v2/clients?status=approved&updated_since=2026-11-10T00:00:00Z"

Keep the response's next_cursor and pass it as cursor until it comes back null.

Verifications and facilities

GET /v2/verifications/{ref} gives one cycle by its V- reference: dates, certificate, scope, risk, whether it's listed, countries of origin, facilities (with whether and when each was inspected) and its status history. GET /v2/verifications/{ref}/facilities lists only the facilities.

Certificates

GET /v2/certificates lists each current cycle with a certificate number: its status, dates, whether it's listed, and license_in_force, whether the participant has a license agreement in force. v1's GET /certificate failed the whole call when one participant lacked an agreement; here it's a flag on each certificate.

To make a Certificate of Verification:

curl -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"kind": "product", "program": "non_gmo", "product": "2-12345-00001"}' \
  https://api.foodintegrityproject.org/v2/certificates/pdf

The answer comes at once, with pdf_url: a lasting link that always gives today's certificate for that request, made from the record each time it's opened. kind can be product, certificate (with certificate_number), participant (with participant_id), brand (with brand_id) or custom (with up to 1,000 TA product IDs in products). Summaries for a participant or a brand list only your TA's products. Products marked Do Not Publish are left out of the link.

Shared opportunities

GET /v2/opportunities lists opportunities shared with your TA or with every TA, and your TA's own. Each shows its share: the access, the scope (summary, contacts) and when it was shared. Contacts appear only when the share includes them and the person agreed to be shared. Was v1's GET /prospect.

Demand for your products

GET /v2/demand?days=90 lists your products that people have asked to see verified, or looked up in scan apps, with the counts and when, and the brands named in requests. Scans count once per app per 2-second burst.

Coming next

Writes (products, packages, verifications and their actions, facility relationships, clients and brands), webhooks when a verification's status changes, and v1's endpoints served by FIP-OS. See Changes and notices.