Partner Integration Worked Examples

Purpose

This document shows how the integration framework applies to concrete partner categories.

Printing company

Role in Tov+

A printing company may exist as:

• vendor actor(s) for human collaboration
• integration principal for system-to-system access

These are separate access paths.

What it can access

• published invitation packages
• printable artifacts intended for print production
• print-ready asset metadata needed for fulfillment
• occasion-level print configuration where explicitly granted

What it must not access

• raw guest portal tokens
• unrelated guest profile details
• planner-only operational notes
• unrelated module data such as chat threads or internal tasks

Appropriate scope model

• occasion scope for a specific occasion
• resource-level access to published_artifact and attached print assets
• optional module scope for publishing-related resources only

Appropriate triggers

• printable.generated
• optional explicit API pull for artifact metadata and retrieval

Notes

• the printer should usually receive only finalized or publishable outputs
• editable planning drafts should remain out of scope unless explicitly needed

Hall / venue

Role in Tov+

A venue may exist as:

• vendor actor/user for human operations staff
• integration principal for layout, event, or schedule synchronization

What it can access

• seating plan outputs for assigned events
• timeline summaries or operational windows if granted
• venue-relevant logistics metadata such as room/layout identifiers

What it must not access

• unrelated guest notes
• global occasion planning data outside assigned events
• private communications threads unless explicitly shared through another channel

Appropriate scope model

• event scope
• module resource access for seating and optionally timeline
• read-only by default

Appropriate triggers

• seating_plan.published
• timeline.updated when venue operations depend on it

Notes

• if venue staff also log in as humans, their vendor-user access remains distinct from machine integration access

Food / catering company

Role in Tov+

A caterer may exist as:

• vendor actors/users for planners and coordination contacts
• integration principal for menu, count, or dietary sync

What it can access

• meal counts
• dietary summaries
• RSVP-derived catering-relevant aggregates
• assigned event schedule windows if operationally necessary

What it must not access

• unrelated guest contact details unless explicitly necessary
• guest token/access records
• general seating data unless catering workflow truly requires it
• unrelated module data

Appropriate scope model

• event scope for relevant dining events
• resource-level read access to catering summaries or filtered RSVP-derived views
• read-only by default unless explicit sync/writeback exists later

Appropriate triggers

• rsvp.submitted
• optional future meal_selection.updated
• periodic sync jobs for aggregate refresh

Notes

• caterer integrations should usually consume summarized or filtered data rather than raw unrestricted RSVP tables

Cross-example lessons

• partner organizations may have both human and machine access paths
• machine integrations should prefer published/filtered/summary resources over broad raw-data access
• scopes should match partner purpose precisely
• webhook triggers should align to meaningful business events, not low-level table churn

Final summary

Printers, venues, and caterers all fit the same integration framework, but each gets a different combination of scope, resource exposure, and trigger behavior. The common rule is least privilege: each partner receives only the business data and event signals required for its role.