External user context

Partition pantry and recipes per end user without FoodAPI user accounts.

Concept

Your application authenticates users. FoodAPI only needs an opaque string — external_user_id — to keep each user's pantry and recipes isolated under your developer account.

FoodAPI never stores email, passwords, or profiles. Send X-External-User-ID (or SDK external_user_id / externalUserId) on requests that should be user-scoped.

Developer vs end user

Developer — API key or portal session; owns the integration.
External user — your app's user id; partitions content inside your tenancy.
Omit the header for developer-global content shared across users.

Example flow

Your App → end user "user_42"
         → FoodAPI with X-External-User-ID: user_42
         → pantry + recipes scoped to DevA + user_42

External user context

Concept

Developer vs end user

Example flow

See also

Next