Skip to main content
The Unified API is BundleUp’s abstraction layer on top of third-party APIs. It provides a single, consistent API surface across integrations while preserving the same execution guarantees as the proxy. Under the hood, the Unified API runs on the same edge infrastructure and follows the exact same authentication, rate limiting, and retry behavior as the proxy API. If you understand the proxy, the Unified API will feel familiar.

​
What the Unified API is

The Unified API exposes normalized endpoints that represent common actions across providers. Instead of learning and maintaining different request shapes for every integration, you call one endpoint and let BundleUp handle provider-specific differences.

​
What the Unified API is not

The Unified API is not a full replacement for provider-specific APIs. It does not attempt to expose every edge case or vendor-specific feature. If you need low-level control or access to provider-unique functionality, you should use the proxy API instead.

​
Connected account

GET /v1/me is the one unified endpoint every integration implements. It answers “who is this connection authenticated as” and returns the same four fields for all of them:
Fields a provider does not expose come back as null rather than being omitted, so the shape is stable across integrations. Some providers authorize at the workspace, portal, tenant or company level rather than the user level. For those, me describes that account instead of a person: HubSpot returns the portal, Stripe the connected account, Xero the organisation, QuickBooks the company file, and Attio and Gong the workspace.

​
Calendar events

GET /v1/calendar/events requires a window: starts_after and starts_before (ISO 8601). Every provider behind it either demands one outright or would otherwise hand back years of history, so there is no default.
Recurring events are expanded into their individual occurrences, so every entry describes a real date. All-day events carry a YYYY-MM-DD date in start_date and end_date instead of a timestamp. status is confirmed, tentative or cancelled. Providers differ in what a “calendar event” is, and in what they can report:
  • Google Calendar and Outlook return calendar events.
  • Calendly returns scheduled bookings, where url is the booking’s API resource.
  • Zoom returns scheduled meetings. There is no web page for one, so url is null, and because Zoom filters on calendar dates rather than timestamps, a window can include meetings from earlier on its first day or later on its last.
Anything the normalized shape leaves out — attendees, conferencing links, organizers — is available through include_raw or the proxy.

​
Execution guarantees

All Unified API requests are executed through the same edge worker as the proxy API. This means:
  • The same authentication model applies. Requests require a Bearer API key and a connection ID.
  • The same per-connection rate limits are enforced.
  • The same retry behavior applies to safe, idempotent requests.
  • The same logging and observability are available.
There is no separate quota, execution model, or reliability layer for the Unified API.