Integration patterns: connecting Onomi to your enterprise systems

Onomi runs inside your enterprise architecture, not beside it. The CRM stays the master of HCP identity, the warehouse stays the home of analytics, and the identity provider stays the front door. This article describes six integration patterns, at the depth an architect needs to place Onomi before integration work starts. Each pattern covers when to use it, what to prepare, and how the connection is configured. It also covers what data moves in which direction, who owns which part, and how to confirm the connection works. The patterns compose. A typical life sciences deployment runs the CRM pattern for HCP records, the identity pattern for internal users, and the BI pattern for the warehouse. The API surface covers whatever remains custom.

Pattern: CRM as the HCP master

Use this pattern whenever engagement data must land on the HCP record, which in life sciences is every deployment. Onomi never forks the HCP master. Your CRM, whether Veeva or Salesforce, remains the system of record for who an HCP is. Onomi resolves event attendees against it and writes engagement back, rather than accumulating a parallel contact database that drifts.

What to prepare, for Veeva: a Veeva CRM org running Veeva CRM Events Management or Veeva CRM Medical Events, and administrator access to install a managed package. Your CRM and event teams also make two decisions together before configuration starts.

• The first is the matching policy, which fields and objects identify an attendee as an existing CRM record.
• The second is the field mapping. It covers three sets of attributes: the attendee attributes matching resolves against, the engagement attributes written back, and the attributes of the event record itself that an approved event brings down with it.

The solution is described in the Veeva SpotMe Sync App product information sheet.

The connector installs as a managed package in your CRM. There is no middleware to build for it, and no specialized integration team to staff. Once installed and configured, four flows run:

1. Event intake. Approved event records in Veeva create the corresponding Onomi events, with organization-level configuration so every event is set up consistently.

   An event created from an arrival is listed in Event requests as a row of its own, at status Approved. It carries its upstream reference and its arrival timestamp in place of a submitted request and an in-platform approval trail. Which filters reach that row is documented in Events approved upstream in your CRM in From approval to execution and auditing requests.

   The inbound mapping carries the event's own attributes. Those are its geography (country and city), its business unit, and, where your organization uses them, its therapeutic area or brand. It also carries the request category, the budget band and its currency, and the dates. It carries no attendee list.

   Attendees are added after the event record exists. On a record-only event, they are added one at a time on the event record with Add attendee. The person who adds them is a holder of the finance role whose scope covers the event. On an event backed by a workspace, they arrive through that workspace's own registration paths. See How to manage transfer of value on your events.

   The attributes above are the dimensions the platform scopes, routes, and reports along. A dimension your organization works with and does not map cannot be used for any of the three. An unmapped business unit, for example, leaves the event outside every business-unit scope, routing entry, and business-unit report.

   The budget band and its currency. Mapping the band and its currency is a prerequisite rather than a refinement. With no request behind the event, they are what the event's approved band and its budget currency are taken from. An event arriving without them has no approved band for the budget controls to read. See Events approved upstream in your CRM, in Budget capture at request and working the budget during planning. For setting the band on a record that has already arrived without one, see Where a budget header carries no band and no budget currency in the same article.

   The dates. The dates are a prerequisite of the same kind. An event arriving with no Start date and no End date starts no reconciliation reminder. It is classified as neither Planned nor Completed on the portfolio calendar, and it pre-fills no travel dates. It leaves a blank-cost policy on the record reading the Budgeted column until the dates are set. On the record-only lane, nothing prompts the closure, because the Reconciliation reminder runs from the End date. The record is closed only when its finance owner selects Close event, and until they do its retention clock never starts.

   Two things recover such an event once it has arrived. The dates are set on the event record itself, as Events approved upstream in your CRM in From approval to execution and auditing requests sets out. The closure is recorded by the event's finance owner with Close event on the budget header, once the record's cost lines are reconciled. That holds whether or not the dates were ever set. See How to use the Budget module.

   The same state is reachable on the portal lane, where a request category omitted Proposed dates or left it optional and unanswered. Approval then fixed no dates. See Configuring the request form and its categories for that cause.

   The request category. The request category is a prerequisite on the same footing. It is the key the Event creation mapping and your approval and reporting surfaces work from.

   The category value the inbound field mapping carries must resolve to an active Onomi request category. A value that resolves to none, because it was never mapped or because the category has since been retired, fails the arrival rather than defaulting to another category. The record stays in your CRM for the mapping to be corrected.

   The failure is visible on both sides rather than silent. No event record is created. The arrival is held with an error your organization administrators read in Held arrivals. The connector's response names the value that failed to resolve.

   A row in Held arrivals shows the value that failed to resolve and the field it arrived in. It also shows the reference of the source CRM record and the arrival timestamp. That is what lets your CRM team correct the mapping, or have an administrator add the category with Add category, and send the record again. See How to set up and use meeting requests and approvals. Revisit the field mapping whenever a category is retired or added. See Configuring the request form and its categories.

   Filtering rules let you decide exactly which events synchronize, so pilots and out-of-scope business units stay out of the sync.

   

2. Registrant synchronization, in both directions. This flow runs on the events backed by an event workspace with a registration journey. That journey holds a registration status for the two systems to reconcile. On those events, attendees can be invited to Onomi events without leaving Veeva. Registrant details and registration statuses reconcile between the two systems regardless of the channel that produced them. Veeva Approved Email campaigns, marketing automation sends, and direct Onomi registration all land on the same record.

   A meeting your organization runs as record-only carries its attendees outbound only. They are added after the event record exists, one at a time on the event record with Add attendee. The person who adds them is a holder of the finance role whose scope covers the event. There is no self-registration link and no list import. They reach your CRM with the meeting record itself, on Meeting record sync, outbound below. See How to manage transfer of value on your events.

3. Engagement write-back. Attendee engagement writes back to the HCP timeline as structured records, close to real time, ready to inform next best actions. That covers registration through attendance to session and content interaction, across event formats including in-person. In a Veeva deployment this is the Veeva CRM engagement write-back. The matching and deduplication described below decide the record each interaction lands on.

   A record your CRM rejects does not stop the rest of the batch, which continues. The platform surfaces no list of rejected write-back records, so a rejection is read in your CRM's own error handling. A write-back gap that persists is raised with your SpotMe Account Manager.

4. Meeting record sync, outbound. The Onomi event's meeting record and its attendee rows travel outbound to the CRM objects your field mapping defines. That happens on every event the connector's filtering rules include.

   On a meeting your organization runs as record-only, this flow is the whole of the CRM path. There is no registration journey for flow 2 to reconcile. It runs when the meeting record is created, and again when the mapped fields or the attendee rows change. On an event that arrived through Event intake, the outbound sync updates the source CRM record the event arrived from. It does not create a second object for the same meeting.

   The flow carries the meeting and its attendees, and it writes back no event lifecycle status at all, Cancelled and Withdrawn among them. Each lane has its own reason for that.

   On the portal lane, the one this flow carries alone, the request and its approval trail live in Onomi rather than in your CRM. So the lifecycle stays on the record that holds it, and your CRM receives the meeting and the people at it.

   Where your governance model approves events in Veeva, the approval trail is the CRM's own, as the upstream paragraph below sets out.

   The consequence is the same on both. A meeting cancelled or withdrawn in Onomi after its record has synced keeps whatever state the CRM record already holds. Build that reconciliation into your own CRM process, on the meetings whose state changed since your last pass.

Where your governance model approves events in Veeva, the two systems split the lifecycle rather than duplicating it. The approved event record flows down to Onomi and creates the corresponding event. Execution and engagement run in Onomi, and registration statuses and engagement write back to the CRM record.

For those events, the approval trail lives in Veeva, which stays the system of record for that decision, and Onomi records execution. The in-tool routing rules, the compliance gate, and auto-approval do not evaluate an upstream-approved event, because governance runs upstream.

Requests raised in Onomi 360's meeting request portal run the platform's own approval lane, with its Event requests, compliance gate, and request statuses. That lane is documented in How to set up and use meeting requests and approvals. The filtering rules above decide which events each lane masters, so the two lanes coexist without colliding.

Self-service meetings reach your CRM on Meeting record sync, outbound, flow 4 of the Veeva SpotMe Sync App connector above. A meeting approved through the meeting request portal syncs like any event, its record and attendees landing as the CRM objects your mapping defines. That holds whether or not the meeting ever had an event workspace. Where your organization runs on Salesforce, the route that carries a record-only meeting's record and its attendees on that lane is settled with your SpotMe team during implementation.

Matching and mapping stay in your hands. Matching runs on the attendees an Onomi event already holds. It resolves each of them against your CRM records, rather than bringing a list of people down into the event. The write-back returns their engagement to the records they resolved to. Matching reconciles those attendees with CRM records across contacts, accounts, leads, or custom objects. It uses rules your administrators chain through multiple fields and objects to sharpen identification. Deduplication keeps repeat encounters from creating duplicate contacts.

Your own team configures field mapping inside the app. There is no fixed limit on custom fields, and no change request to us when your data model evolves. You also decide which engagement activities enter the CRM at all. Relevant activities are saved as objects or attributes you define. Only the data your business needs enriches the record, and your Veeva storage stays under your control.

Consent narrows what flows before any of those choices do. Consent is a first-class field on every attendee record, captured with your organization's configured wording where the event runs a registration journey. What it gates is the engagement data an event captures in a workspace: the registration data itself, and the session and behavioral signals captured while the event runs. That is what flows 2 and 3 carry, so a declined or missing consent withholds that data from the write-back.

Flow 4 sits outside the gate. It carries the Onomi event's meeting record and its attendee rows on every event the connector's filtering rules include. That holds whatever the consent state reads.

On an event that ran a registration journey both parts apply at once. A healthcare professional whose consent state reads Consent declined is withheld from the flow 2 and flow 3 write-back. Their attendee row and the attendance state recorded on it still travel on flow 4. Each row carries its consent state, so the receiving system applies its own rules to it.

On a meeting your organization runs as record-only, flows 2 and 3 do not run at all. No registration journey exists, so nothing the gate governs was captured. Flow 4 is the whole of the CRM path there. Each row carries the attendance state recorded on it and the consent reference held on the healthcare professional's master identity. The state carried is the one on the attendee's row, which reads No state recorded where none has been set, so an unrecorded attendance still syncs as a row rather than being withheld.

The consent model itself and the states the field takes are set out in HCP registration and validation on your events. For your responsibilities as controller, see the Data privacy guide.

For Salesforce, event attendance and registration auto-associate with Contact and Account objects, with no manual entry by your event operations team.

Marketing automation extends the pattern. Registration data also reaches platforms such as Marketo and Salesforce Marketing Cloud, through the CRM or a direct API connection. A status change can then drive a post-event journey.

The Marketo integration is live today as a workspace module. Your administrator installs it from Marketplace > Integrations, connects it with your Marketo LaunchPoint credentials, tests the connection, and enables automatic synchronization.

It then moves data in both directions. Leads push from Marketo into Onomi, with each lead's personal event access link returned to Marketo for use in your campaign emails. Leads and registrations push from Onomi to Marketo. Attendance and live stream engagement flow back, optionally mapped directly to the Marketo program member status, so participation updates lead statuses automatically. The step-by-step setup is in the Marketo integration guide.

The pattern runs direct or brokered. The connector talks to the CRM itself. Where your architecture routes cross-system traffic through an integration layer, the same structured records travel through that layer under the same data contract (see the next pattern).

To confirm the connection works, run one event end to end in a sandbox. Approve a test event record in Veeva and check that the corresponding Onomi event is created. Register a test attendee through each channel you use, and check that the registration statuses reconcile on both sides. Then check the test contact's timeline for the attendance and engagement records.

Ownership: your CRM team owns the HCP master, the matching policy, and the field mapping. It configures all three in the connector, without a change request to us. Onomi owns the connector, its schema, and its maintenance as both platforms evolve.

Pattern: event-streaming middleware

Enterprises that run a streaming or middleware layer between their systems of record, on streaming platforms such as Apache Kafka, usually made that choice deliberately. The choice is one governed backbone instead of a point-to-point mesh. Onomi is built to connect to that layer rather than bypass it. Where the layer exists, Onomi connects to it, and the layer talks to the CRM, the ERP, and everything downstream.

The flow has two halves, one polled and one pushed. The pull half runs today on the documented APIs. Your integration layer consumes Onomi data through the REST and Analytics APIs described in the next two patterns, on the schedule and in the shape it controls.

Operational records come through the REST API. Its changes-since endpoint returns only the records modified after the timestamp the layer passes, so each cycle moves deltas rather than full datasets. Reporting datasets come through the Analytics API as CSV or parquet files. Records flow back in through the same REST API, under the same authentication, batching, and rate rules as any other API consumer.

Native event publication adds push delivery, available since the 2026.01 release. Lifecycle events publish to your streaming layer as structured messages against a documented schema. Those events run from event requests and approvals to registrations, attendance, and cost actuals. Each message describes one business fact. So the same delivery can feed the CRM through your existing topics, the ERP for cost actuals, and the warehouse for analytics, without Onomi knowing how many consumers exist.

Delivery is at least once. A consumer should treat a repeated message as an update rather than a new fact, keyed on the record identifier the message carries. That is the same discipline as the upsert writes described in the next pattern. What happens after delivery, who subscribes and what gets transformed, stays inside the layer.

Note: The record-only boundary narrows both halves of this pattern. The pull half runs through the REST and Analytics APIs, so it inherits the exclusion set out in the API surface pattern below. Native event publication covers the same workspace-backed events.

Each part of a meeting your organization runs as record-only is read on the surface that holds it. The request and its approval trail are read in Event requests and its 10,000-record export. The costs are read in the Costs report and the costs entity of the report builder. The confirmed allocation is read on the event record's Transfer of value module. The meeting record with its attendees is read through the CRM sync described in the pattern above.

That export covers up to 10,000 records, and a larger run is refused rather than truncated. Where a larger extract is needed, it is taken as narrowed repeat exports by period, geography, or business unit. The export is not schedulable.

To confirm the pull half works, have the integration layer authenticate with an API token. Then read one workspace's changed records through the changes-since endpoint twice. The second read, passed the first read's timestamp, returns only what changed in between, which is the loop the layer will run in production.

Ownership: the middleware stays yours, on purpose. Topics, message contracts, transformation, routing, and every downstream consumer remain under your IT governance. Onomi's responsibility is to deliver structured, schema-documented data at the boundary and to process what the layer sends back. Adding or retiring a downstream system never requires a change on the Onomi side.

Pattern: the API surface

Use this pattern for integrations your own developers build: a portal, an internal tool, or a system without a packaged connector. Use it for bulk data movement in either direction too.

The API surface is REST: JSON request and response bodies over HTTPS. One idiom is worth knowing up front: writes are upserts. A POST that carries a record identifier updates the existing record instead of duplicating it, which makes integration jobs safely repeatable. Endpoints are organized in families, all documented on the developer portal at developer.spotme.com. Organization endpoints enumerate the event workspaces under your organization. Workspace endpoints read and write the records inside one workspace: people, speakers, sessions, session registrations, documents, and sponsor content. Module endpoints cover module-specific data. The workspace API base URL is https://api.spotme.com/api/v2/workspace.

One boundary matters when you size a warehouse, and it is a boundary on what these two APIs read. The read endpoints of the REST API and the Analytics API address events that are backed by an event workspace, which is what their organization and workspace endpoints enumerate.

Meetings your organization runs as record-only have no workspace created for them, so those endpoints do not address them. Each part of such a meeting is read on the surface that holds it. The request and its approval trail are read in Event requests and its 10,000-record export. The costs are read in the Costs report and the costs entity of the report builder. The confirmed allocation is read on the event record's Transfer of value module. The meeting record with its attendees is read through the CRM sync, where they land as the CRM objects your mapping defines.

The attendance recorded on such a meeting's attendee list is not read in the platform's standard reports or in the report builder. It is read in three places: the event record's attendee list itself, the Meetings entries in Contacts, and the CRM sync.

The exclusion does not reach the inbound cost and invoice flow documented below. That flow addresses the event record itself rather than a workspace. Whether a request category creates a workspace or stays record-only is a setting, documented in How to set up and use meeting requests and approvals.

A data model diagram in the documentation maps the entities and their connections. The endpoint reference lists every attribute of every entity. Your developers can see the full shape of a record before writing a line of code. Start with Getting started with the REST API and the REST API overview.

Access is governed at two levels, both in your hands. Your organization administrator grants a Backstage user Developer API access, at the organization level rather than per workspace. Two organization roles can hold that grant and no others. An organization Admin holds Developer API access by default and cannot have it removed. An administrator can enable it for a person holding an Organizer role. So a user provisioned with the Member or Guest organization role cannot be granted it, and cannot complete the token flow below at all. See Role-based access and visibility for internal and external stakeholders. A user who holds the grant then creates a bearer token in Backstage:

1. Open your profile from the initials at the bottom left of Backstage and select the API tokens tab.
2. Select Create a token and name it after the application that will use it.
3. Store the token in your secret store immediately: it is displayed only once, at creation.

Every call then carries the token in the authorization header (Authorization: Bearer <token>). A token is personal and reaches exactly what its owner can reach. So the common enterprise practice is a dedicated integration user per connected system. That keeps access reviewable, and makes revocation a one-token action.

Size that user's reach from the organization role it holds rather than from its workspace list. An integration account holds an Admin or an Organizer organization role, since those are the only two the grant reaches. Both carry organization-wide rights. An organization member who reaches a workspace without being added to it works there with Editor permissions. The Guest organization role is the one carved out of that behavior, and it is also the role that cannot hold the grant at all. See Role-based access and visibility for internal and external stakeholders.

Adding the integration user to each workspace the integration touches is still worth doing, deliberately and event by event rather than assumed from the grant. It keeps the account's intended reach visible to an access review. It is not what bounds the credential. Two things do. The first is the organization role the account holds, which is what its token reaches. The second is revocation: the token is deleted from the same API tokens screen at any time.

High-volume loads run through validated bulk import and export rather than record-by-record calls. A single call carries up to 5,000 documents or 5 MB of payload. The API is rate-limited to 3 requests per second, with bursts to 5, per API user, and answers with a 429 status when the limit is exceeded. In practice a 20,000-registrant load is four batched calls, not 20,000 requests.

Two published recipes cover the most common builds.

• The customer portal recipe puts your own portal in front of event access. The portal authenticates the user, lists upcoming events through the organization endpoint, and registers the user by creating a person record in the chosen event's workspace. That call returns the registrant's personal access link (magic link). Your portal or email platform delivers it, so the attendee reaches the event in one click, with no second authentication step.
• The CRM recipe keeps a third-party system consistent with registrant data. A scheduled job you host enumerates the relevant event workspaces, and reads each one's records changed since the last run through the changes-since endpoint. It applies your field-level mapping to create or update records on the other side. It stores cross-reference IDs, so later changes reconcile instead of duplicating.

Sub-pattern: ERP costs and invoices settling event cost lines

One inbound flow on this surface is worth documenting in its own right, because it is what closes an event's money. The direction of travel is inbound. Your ERP posts settled invoices to Onomi, under the same authentication, upsert, batching, and rate rules as any other write described above. It moves no boundary between the two systems. Your ERP stays the system of record for accounting and payment, and Onomi records the outcome against the event. That is the same split the ERP has as a downstream consumer of published cost actuals in the patterns above.

The connection carries five values per invoice. They are the reference of the event the invoice belongs to, and the reference of the cost line it settles. The other three are the invoice reference, the settled amount and its currency, and the invoice date.

Two of those five are identifiers, and the match runs on them in that order. The event reference resolves the event first, so an invoice lands on the event it was raised for rather than being searched for across the portfolio. The cost-line reference is then matched inside the event it resolved to.

That reference addresses the event record, so this connection reaches every event record your organization holds, with a workspace or without one. A record-only meeting's cost lines settle through it exactly as How to use the Budget module documents.

A settlement is a cost-line save. So an invoice that settles a line's Actual amount evaluates that budget's policies exactly as a typed save does. A threshold or blank-cost exception a landed invoice raises notifies the recipients named on the policy that raised it. A settled Actual total that passes the approved band raises the over-band flag on the budget header, which notifies the event's finance owner. Both run on the terms How to use the Budget module publishes for the policies and their notifications.

It also means the post does not go to the workspace API base URL above, which addresses the records inside one workspace. The endpoint the connection uses is settled with your SpotMe implementation team when the connection is scoped. That is the same way as the outbound leg of the cost-line reference described next.

The cost-line reference is the value whose round trip has two halves, and they are owned differently. The outbound leg gets a cost line's reference to the system that raises the invoice. It is designed with your implementation team per deployment, rather than carried by a fixed route of ours.

The reference itself is Onomi 360's own reference for the cost line. The commitment your process raises carries it out with the committed amount it was raised for. So the invoice comes back quoting the same value the connection matches on. No planner enters that reference on a cost line. Its form for a given deployment is settled with your SpotMe implementation team when the connection is scoped.

The inbound half does not depend on how that was arranged. The invoice comes back carrying the reference. It is matched to a line on a value both systems already hold, rather than on a name, a date, or an amount.

Neither match is guessed at, and the two failures end differently. An invoice can resolve to an event and still match no cost line on it. That invoice is recorded against the event as unmatched and read in the event's Unmatched invoices view, rather than settling the wrong line or creating one. An invoice whose event reference resolves to no event is refused at the connection. It is returned to your posting system as a failed write, under the same error handling as any other write on this surface. It is never recorded against an event, and never lands in a view somebody has to find.

Currency is the sixth thing this connection turns on, after the five values it carries. It is the one an integration team designs an error path for before the first post.

An event budget is kept in one currency, and nothing is converted. So an invoice whose currency differs from the event's budget currency is not applied to the cost line. It is recorded against the event alongside the unmatched invoices, and listed for the event's finance owner. The integration posts in the event's budget currency, which is the value the connection expects.

Local-entity invoicing against a regional budget is where this is met. Agree the posting currency with your ERP team while you agree the reference round trip.

The GL code is the seventh thing this connection turns on. It is the first of two cases where both references resolve and the invoice still does not settle.

An invoice whose event reference and cost-line reference both resolve, but whose GL code matches no cost category on that budget, is not applied to the line. It is recorded against the event in the Unmatched invoices view, with the GL code named as the value that failed, and it raises no notification. It settles once the invoice is resent carrying a GL code your category mapping matches. It also settles once the event's finance owner enters the actual on the line and dismisses the row with a reason.

A chart of accounts that has moved on since the mapping was configured is where an integration team meets this. Agree the GL codes in scope with your finance team while you agree the reference round trip. The mapping itself is documented in How to use the Budget module.

A confirmed allocation is the eighth thing this connection turns on. It is the second case where both references resolve and the invoice still does not settle.

An invoice whose event reference and cost-line reference both resolve, but whose target line has already been read by a confirmed allocation, is not applied over the confirmed figure. It is recorded against the event in the Unmatched invoices view, with the allocation named. It raises no notification. How it settles depends on whether the allocation's handoff has been delivered. While nothing has been delivered, the event's finance owner reopens the allocation and the invoice is resent. Once the handoff has been delivered to any connected destination, Reopen is no longer offered. The correction runs through the versioned Correct allocation path instead. After that the invoice is resent, or the row is dismissed with a reason.

Allocation runs after reconciliation, so a late invoice against an event whose transfer of value has already been confirmed is where an integration team meets this. Reopening a confirmed allocation and correcting a delivered one are both documented in How to manage transfer of value on your events.

All four of those paths land in one place, on the event rather than in a log. The event's Budget module carries an Unmatched invoices view. It is opened by the holders of that budget's per-event writes: holders of the finance role whose scope covers the event, and the planners of the event's workspace. On an event with no workspace the finance role alone opens it. See Role-based access and visibility for internal and external stakeholders.

Each row carries the invoice reference, the settled amount and its currency, the invoice date, and the value that failed to match. That last value is one of four:

• The cost-line reference the invoice arrived with.
• The currency, where that is what stopped it.
• The GL code the invoice arrived with, where no cost category on the budget matches it.
• The confirmed allocation that had already read the target line, where that is what stopped it.

A row landing in that view raises no notification, and no view lists unmatched invoices across events. So the Unmatched invoices view on the event is read by the event's finance owner as part of the reconciliation pass, rather than waiting to be announced. See How to use the Budget module.

A row clears in one of two ways.

• Your ERP sends the invoice again, with the correct cost-line reference and in the event's budget currency. That matches the invoice to the cost line, settles it, and takes the row off the list. On a row the GL code stopped, the resend carries a matching GL code. On a row a confirmed allocation stopped, the resend follows the reopening, or the confirming of the correcting version where the handoff has already been delivered.
• The event's finance owner enters the actual on the line directly and dismisses the row with a reason. That keeps the row, its reason, and who dismissed it on the event record.

Ownership splits as it does in the patterns above. Your ERP team owns the outbound post and the round trip of both references: the event reference the invoice is posted against, and the cost-line reference it settles. Your Onomi administrator owns the event mapping.

To confirm the connection works, post one invoice carrying a test event's reference and the reference of one of that event's cost lines. Then open that event's Budget module and confirm the line shows its Actual amount and its Invoice reference. See How to use the Budget module.

For a small set of actions, Onomi calls you instead of waiting to be polled. Organization administrators can configure webhooks that send a signed JSON POST to your endpoint. The triggers are a user requesting data erasure or export, a user unsubscribing from emails, and a workspace being created. That is how privacy tooling and workspace-provisioning automation typically hook in. Broader lifecycle publication into a streaming layer is the middleware pattern above.

GraphQL is not offered. The data scope a GraphQL interface would serve is cross-entity queries over events, attendees, and engagement. That scope is covered by the REST APIs for operational data and the Analytics API for reporting data.

To confirm access works, call the workspace-listing endpoint with the new token. It returns the workspaces the token can reach, and it is the natural first call of most integration jobs anyway.

Ownership: your developers own the integration code and its lifecycle. Your administrators govern access through the Developer API access grant and the tokens issued under it. Onomi owns the API documentation and keeps it current as the platform evolves.

Pattern: procurement and the sourcing award

Use this pattern where your procurement platform needs the outcome of venue sourcing. The boundary is settled and comes first. Purchase requisitions and purchase orders are raised, approved, and closed in your procurement platform. Onomi neither raises nor mirrors them.

Onomi is the system of record for the event, and the sourcing outcome lands there. The award and the final contracted costs sit on the event record. The awarded amount is written to the Committed column of the budget category that carries the Sourcing award target value the award needs. The executed contract is stored on the record with the rest of the event's paper. See How to source a venue from your event, and How to use the Budget module for the award-to-budget write.

The connection is outbound and implementation-scoped rather than a packaged connector. Which of those values your procurement platform consumes, in what shape, and on which trigger, is designed with your SpotMe implementation team per deployment. That design runs on the surfaces this article documents.

Two of those surfaces carry it.

• On the API surface, the integration addresses the event record itself, as the ERP cost and invoice flow above does. The endpoint it uses is settled with your SpotMe implementation team when the connection is scoped, rather than published as a fixed route of ours.
• On the reporting side, the documented export surfaces of the program layer carry the money. Those are the Costs report, the costs entity of the report builder, and their scheduled exports. See How to use Onomi 360: the portfolio calendar, engagement view, and reports.

To confirm the connection works, run one award end to end. Award a test sourcing request, and confirm the awarded amount lands in the Committed column on the event's Budget module. Then confirm the scoped integration delivers the award and the final costs to your procurement platform, in the shape your implementation defined.

Ownership: your procurement team owns the requisitions, the orders, and the process behind them. The scoped integration is defined jointly with your SpotMe implementation team. The event record stays the system of record for the award and the final costs it delivers from.

Pattern: BI and the data platform

Reporting inside Onomi covers the operational layer. The reporting surface, what it holds and when it becomes available, is documented in How to use Onomi 360: the portfolio calendar, engagement view, and reports. This pattern is for the enterprise view. Event and engagement data lives in your own warehouse next to CRM and omnichannel data, modeled by your BI team. BI connectivity is what this pattern delivers: supported feeds against a documented schema, into the stack you already run.

The Analytics API is a dedicated reporting surface, separate from the operational REST API and built for analytical reads. It is a REST-based file API that serves reporting and engagement data across events as CSV or parquet. Warehouses such as Snowflake, BigQuery, and Amazon Redshift ingest those formats natively, as do tools such as Power BI, Tableau, and Qlik.

Rate limits apply to API calls, not to the files they return, so a full-history load arrives as one large file rather than a paging loop. The Analytics API documents the same 3 requests per second, burst 5, and 5,000-document and 5 MB call limits as the operational REST API. The reference at developer.spotme.com/docs/analytics lists every entity and attribute. It provides an OpenAPI specification that works with tools such as Postman.

Three properties matter architecturally.

• Data is served at two scopes. Organization scope covers cross-event reporting within one organization, using the organization-scope Analytics API developer role (account_api_developer). Customer scope covers reporting across your organizations, for benchmarking across countries, divisions, or sectors, using the customer-scope Analytics API developer role (customer_api_developer).

  Both scopes of the role are enabled by SpotMe through your Account Manager; the procedure is documented in the Assigning and removing roles section of Assigning roles, enterprise sign-in, and provisioning.

• Archived workspaces stay readable through this API. An archived workspace is no longer reachable through Backstage or the operational REST API without a restore. The Analytics API continues to serve its data, so reporting does not stop when an event team archives its workspace.

  That readability follows the workspace's own retention. A workspace archived for more than two years is deleted, and its event and engagement history goes with it. Any history your warehouse needs beyond that window is loaded while the workspace still exists. See How are workspaces archived or deleted?.

• And both surfaces authenticate with a bearer token.

  The Analytics API is enabled per organization by SpotMe, and its developer role is enabled the same way. Those endpoints authenticate with a bearer token created for a holder of that role. Where that token is created is settled with your SpotMe Account Manager when the API is enabled.

Connecting a BI tool is a query, not a connector installation. In Power BI, for example, create a blank query. Then paste the documented Power Query M snippet that calls the events endpoint with your organization ID and CSV as the format. Authenticate with your API token as the web API key, and the dataset lands as a table. The single-source guide walks through the query, column typing, date conversion, and derived columns. Its companion article covers loading and joining multiple entities into one model. Warehouse loading follows the same shape: scheduled pulls per entity into your staging layer, modeled onward by your BI team. The general surface is described in the Analytics API overview.

Note: Test workspaces appear on the events entity, but their detailed data points are not extracted, and their records carry no aggregated counts. Test activity stays out of production dashboards without extra filtering.

Note: The record-only boundary described in the API surface pattern above applies here as well. This API serves the events backed by an event workspace. Each part of a record-only meeting is read on the surface that holds it, as that pattern sets out.

Scheduled structured exports deliver recurring extracts without an engineer in the loop. Live feeds push data into your warehouse as it changes, for dashboards that follow the event rather than the export schedule. Both are available since the 2026.01 release. The Analytics API is enabled per organization: to activate it, please contact your SpotMe Account Manager.

A second boundary applies to the extracts and the live feeds alike. It holds for events backed by a workspace as much as for record-only meetings. Three of this article's patterns carry data out to your systems on routes of ours, and each carries something different. The procurement pattern above moves the award and final costs out as well, on an integration your implementation scopes rather than on a route of ours.

• The CRM sync, through the Veeva and Salesforce connectors described in the CRM as the HCP master pattern above, carries what that pattern names. That is the event or meeting record and its attendees, and the engagement write-back on the healthcare professional's timeline. It also carries the registrant details and registration statuses that reconcile in both directions, on the events backed by an event workspace with a registration journey. A record-only meeting has no registration to reconcile, and carries its attendees outbound only.
• Native publication to your streaming layer, described in the event-streaming pattern above, carries the lifecycle events that pattern names.
• This API, together with the scheduled exports and the live feeds that run on it, carries the workspace-backed event, registration, attendance, and engagement data the entities above describe.

Three further outbound integrations are documented elsewhere in this package rather than as patterns of their own here. The transfer-of-value handoff delivers the confirmed per-country allocations to your connected transparency destinations (see How to manage transfer of value on your events). The reimbursement claim is routed to your connected expense or finance system (see How to manage payments, honoraria, and reimbursement on your events). The travel request is delivered to a travel team's connected travel system (see How to manage travel and accommodation for your event).

What follows names the surfaces the remaining records are read on inside the platform. Through this API the strategic meetings management records are not served. The extracts and the live feeds running on it do not carry them either. Those records are read elsewhere, each on the surface that holds it.

They are also reported on. The Onomi 360 standard reports and their scheduled exports cover five groups: requests and approvals, sourcing and RFPs, registrations and attendance, events live and past, and financials. Alongside them sit the reinvoicing summaries prepared for cross-charging and reconciliation. The same records are read on the dashboards at global, regional, or country level. See How to use Onomi 360: the portfolio calendar, engagement view, and reports.

Two of those record classes keep a fuller home outside the reports.

• The audit-grade record of a request means the request together with its logged events. It is taken out through the Event requests export of the records in view. One export covers up to 10,000 records, and a larger run is refused rather than truncated. For a bigger extract, run narrowed repeat exports by period, geography, or business unit. The export is not schedulable. See How to set up and use meeting requests and approvals.
• The confirmed allocations and the transfer-of-value handoff are worked on the event record's own Transfer of value module. The Transfer of value report reads from that module rather than replacing it. See How to manage transfer of value on your events.

The handoff itself is the route that delivers those allocations onward. See Running and correcting an allocation, Transmitting disclosure records to transparency systems, and How to use Onomi 360: the portfolio calendar, engagement view, and reports.

That boundary is a property of this API and the feeds that run on it, rather than of the platform. So it does not narrow what native publication or the CRM sync delivers. Each of those carries exactly what its own pattern above names.

To confirm the connection works, pull the events entity as CSV with your token. One row per event, carrying the aggregate counts, means authentication, scope, and format are all correct. Every other entity follows the same call shape.

Ownership: your BI team owns the models, the dashboards, and the joins to non-event data. Onomi owns the Analytics API schema and its documentation. For what the data itself contains, the entities and the reporting model, see How to use Onomi 360: the portfolio calendar, engagement view, and reports.

Pattern: identity and provisioning

This pattern is always on for internal users: no separate Onomi credentials, sign-in through your identity provider.

Single sign-on supports SAML 2.0, OAuth 2.0, and OpenID Connect. Azure AD / Entra ID, Okta, Google, and other providers compatible with those protocols all work. The SAML implementation is service-provider-initiated, signs its authentication requests, and supports assertion encryption. OpenID Connect supports the authorization code flow (recommended) as well as the implicit flow. Email is the unique identifier: the address your identity provider asserts is the identity Onomi keys on. Protocol details and requirements are in the single sign-on article.

What to prepare depends on the protocol. For SAML 2.0, your identity team provides the IdP's federated metadata XML file, plus test credentials. Where no metadata file is available, they provide the sign-on URL and the IdP's public X.509 certificate instead. For OpenID Connect, the discovery URL (or the individual authorization, token, user info, and key endpoints), a client ID, and a client secret. For OAuth 2.0, a client ID and client secret. The connection is configured with your SpotMe team against these inputs and proven with the test credentials before rollout.

Just-in-time provisioning is available, and it is configured per SSO connection. Where it is enabled, the account is created, and kept updated, at first sign-in from the user information in the SAML assertions your identity provider sends. Those workspaces then need no pre-loaded user list and no manual creation step. See SSO JIT provisioning.

Workspace placement uses one of two matching modes.

• In EID mode, your identity provider stores the event identifiers a user may access, and the user is added to those workspaces at sign-in.
• In profile field mode, a field held in your IdP, such as country or department, routes the user to the matching workspace.

Any profile field the assertion carries can be imported and made available in the workspace, on the user's profile and for targeting and personalization by administrators. Access rights follow the organization and workspace roles a user holds. Your organization administrators assign those, as documented in Role-based access and visibility for internal and external stakeholders.

Note: Profile photos are not imported through the assertion; every other profile field is eligible.

To confirm the setup works, sign in with the test credentials. The account should be created at first sign-in, land in the workspace the matching mode selects, and show the imported profile fields on the user record.

Ownership: the identity lifecycle stays in your identity provider.

Joiners gain sign-in access at their first sign-in through the SSO connection. Their organization and workspace roles are assigned by your organization administrators. Where just-in-time provisioning is enabled, that first sign-in also places the account in the workspaces the matching mode selects from the assertion. That placement creates a workspace user record, the app-side profile the workspace's Users module holds, with the imported profile fields on it. It is not membership of the workspace team. The organization role, the workspace role, and any strategic meetings management assignment stay with your administrators. What that placement does and does not carry is documented in How scope and workspace membership meet in Agency access and strategic meetings management scope. Disabling a leaver's identity at the provider ends the federated sign-in path, so that person cannot reach Onomi while the identity is disabled. The conditional access policies your identity team enforces there, such as MFA and device checks, apply to Onomi sign-in as to any service behind your IdP.

Onomi owns the model behind the organization, workspace, and content hub roles, which your organization administrators manage in Backstage. Strategic meetings management roles are a separate access layer. Organization administrators grant and scope them in Onomi 360 > Policies > Users and roles. Those assignments must also be removed there during offboarding.

The disable does not clear an assignment. It stays granted on that list, and it appears in none of Backstage's offboarding lists. It takes effect in full again the moment a sign-in path is restored, whether that is a re-enabled identity, a rehire, or an identity that was never disabled. A leaver who keeps an Approver, Compliance reviewer, finance, program-lead, program-owner, or Sourcing assignment therefore keeps everything its scope shows, as soon as they can sign in again. That is why the assignment is the first layer removed.

A bearer token is a layer of the same kind, and it sits outside your administrators' lists for a reason of its own. A token issued under Developer API access is personal, and it lives on the API tokens tab of its holder's own profile in Backstage. No administrator list shows another person's tokens, so it is retired there by its holder before the account is disabled.

A third layer sits outside those lists for a reason of its own again. The organization-scope and customer-scope Analytics API developer roles (account_api_developer, customer_api_developer) are enabled by SpotMe through your Account Manager rather than by your administrators. So they appear on none of Backstage's administrator lists and on none of Onomi 360's. Neither the disable at your provider nor removal of the account's organization membership retires them, or the bearer token those endpoints authenticate with. Both are retired by asking your SpotMe Account Manager.

Remove the assignments, retire the tokens, and ask for the Analytics API roles to be removed as part of that process. The order of all three layers, and the removal route for each, is in the Assigning and removing roles section of Assigning roles, enterprise sign-in, and provisioning.

Note: Integration guarantees tied to named systems are agreed per customer and documented in your deployment's solution architecture. Those guarantees cover middleware topics and message contracts, latency commitments, environment counts, and version-support windows.

* Onomi 360 MeetingsEQ exclusive capabilities.