ivvycode/apidocs

This repository is not an application runtime; it is a GitBook-style API documentation site for the iVvy platform. The main architectural concern is the documentation information model: shared API foundations first, then product-specific API surfaces, then change notices and integration guides.

1. Repository purpose

- The repo defines the public developer portal for iVvy APIs.

- Content is authored as Markdown pages, organized into product domains and support/reference sections.

- The README and SUMMARY.md indicate a book-like navigation structure rather than executable code.

2. Top-level platform boundaries

- The docs are split by business domain:

- contact/ for Contacts CRM

- crm/ for lead/activity/task workflows

- events/ for event management APIs

- venues/ for venue operations and booking

- invoice/ for invoicing and payments

- account/ for account/admin lookup and error reporting

- partner/ for partner/booking-engine distribution APIs

- These map directly to distinct API subsystems in the iVvy platform.

3. Shared integration foundation

- getting-started/ is the cross-cutting integration layer.

- It covers request construction, signing, headers, encoding, pagination, filtering, exceptions, and date/time formats.

- This section is the architectural boundary between external clients and the API platform: all product APIs appear to rely on the same authentication/request-signing model.

4. Request/response contract documentation

- The “creating the request” and “interpreting the response” guides document the common protocol used by all API families.

- The development-reference/ folder contains low-level rules such as MD5, HMAC-SHA1, JSON encoding, URL encoding, timestamp/timezone formats, and address formatting.

- This suggests a strongly standardized API contract across products, with cryptographic request signing and shared data encoding conventions.

5. Events subsystem

- events/ covers event lifecycle data: events, sessions, speakers, attendees, registrations, invited contacts, sponsorships, and login tokens.

- This is a self-contained domain centered on event operations and participant management.

- The presence of create-login-token.md implies integration points for authenticated attendee or organizer access flows.

6. Venue operations subsystem

- venues/ is the largest domain and is split into two major sub-areas:

- venuedata/ for master/reference data and availability lookup

- getoraddbookingdata/ for operational booking workflows

- venuedata/ exposes venue configuration objects such as function spaces, rooms, packages, resources, rate plans, taxes, revenue templates, and inventory.

- getoraddbookingdata/ handles bookings, sessions, attendees, notes, payments, refunds, documents, status changes, and opportunity conversion.

7. Accommodation-specific venue flows

- venues/accommodation/ is a specialized booking branch for room reservations and accommodation booking management.

- It includes reservation creation/update, confirmation, cancellation, status changes, guest contact updates, room counts, and dynamic rates.

- This indicates a separate accommodation workflow layered on top of the broader venue booking model.

8. CRM and contact model

- contact/ focuses on people and organizations: contacts, companies, notes, subscription groups, custom fields, and lead-related add/update endpoints.

- crm/ focuses on pipeline operations: leads, opportunities, activities, tasks, and classification taxonomies such as source, stage, quality, type, channel, and purpose.

- Together, these two folders represent the customer and pipeline data model used by multiple product areas.

9. Commercial and accounting surfaces

- invoice/ documents invoice retrieval, credit notes, payment posting, and invoice options.

- account/ contains administrative utilities such as cost centers, industry lists, user lists, email logs, and error reporting.

- These folders expose operational and financial integration points that sit alongside the core CRM/venue/event domains.

10. Notifications and event-driven integration

- notifications/ documents endpoint subscriptions and domain-specific notification channels for contacts, companies, CRM, events, payments, and venues.

- This is the repo’s push-integration layer: instead of clients polling every resource, they can subscribe to domain events.

- The existence of separate notification pages per domain suggests loosely coupled outbound hooks from the iVvy platform to external systems.

11. Announcements and versioning

- announcements/ captures product changes and breaking-change notices, grouped by domain.

- This is the documentation-side change management layer, helping consumers track API evolution across contacts, invoices, venues, and other modules.

- It signals that the platform is versioned and that client integrations need to account for incremental schema/behavior changes.

12. Use-case and solution-oriented navigation

- getting-started/use-cases/ groups documentation by consuming system type: accounting systems, CRM systems, point of sale, and property management systems.

- This shows the intended integration architecture from the consumer perspective: external systems connect to one or more iVvy domains depending on business role.

- The docs therefore serve both as API reference and as solution architecture guidance.

13. Tooling and repository shape

- The presence of .gitbook/, SUMMARY.md, and extensive Markdown files indicates GitBook as the documentation framework.

- nbproject/ is editor/project metadata and does not appear to affect the public documentation architecture.

- There is no application service code, database schema, or runtime infrastructure in this repo; the main “system” is the documentation site itself.

14. How to diagram this repo accurately

- Draw the center as a documentation portal with shared integration guidance feeding into product domains.

- Show the product domains as separate bounded contexts: Contacts CRM, CRM pipeline, Events, Venues, Invoice, Account, Partner.

- Add cross-cutting layers for request signing/authentication, response conventions, notifications/webhooks, and change announcements.

- The implied external system boundary is between third-party client applications and the iVvy API platform, with this repo documenting the contract between them.