Connecting your customer data to HubSpot.

Today a customer's history is spread across your systems: purchases in store and online, registered watches, repairs under way. This project brings that history into HubSpot so three teams can act on it.

• Marketing can segment on real purchase behaviour and run journeys from it: recent buyers, lapsed customers, spend bands, the categories they buy.
• Service sees purchases, warranty registrations and repair jobs (status, due date, job number) beside every conversation, without needing the customer to supply proof of purchase.
• Boutique teams capture a walk-in's details on a tablet, follow up automatically with the products they viewed, and see the same profile when the customer returns to purchase.

HubSpot becomes the engagement layer and receives the subset marketing, sales and service need. Your systems stay the source of truth. Nothing in this build changes that.

Oracle is the master. Retail Express retail data, online orders and warranty registrations already interface in nightly, and your team is building Retail Express APIs that will bring that feed close to real time. HubSpot connects to Oracle, and to nothing else.

Your developers own the interfaces, built API and webhook first through the OCI API Gateway. There is no Kongo middleware in between: a layer between two systems that already communicate over APIs adds a component without adding value. If a requirement emerges that cannot run through the gateway, a middleware fallback remains available; we don't expect to need it.

Your team owns the integration. Our job is to make HubSpot a known quantity: a technical scope of work naming the exact endpoints to read from and write to, guidance through implementation, and the HubSpot build itself.

Freshness follows your Retail Express feed: in-store sales reach Oracle nightly today, and close to instantly once your Retail Express APIs are live. HubSpot reflects whatever Oracle holds.

Marketing and service need different shapes of the same data, so we model it twice.

Rollups on the contact

Last purchase date, lifetime spend, order count, categories bought and a lapsed flag, kept current on every contact. These drive lists, segments and journeys without opening individual records.

Records for service

Each order, warranty registration and repair job as its own record, associated to the contact: what was bought and when, what's registered, and where a repair sits (status, due date, job number). When a ticket lands, the agent sees this history beside the conversation.

The product catalogue comes across too, into HubSpot's product object: categories, descriptions and the detail the boutique follow-up emails draw on (section 06). The one sizing decision left is depth on sales history: order level records, or every individual line item. We'd settle that together before building.

Images

Product images sit on a private network today, so there's no URL an email can reference. Three workable options, in rough order of effort:

• Reuse the public website's imagery where it already exists: if a product's image is already served on your site, the feed just carries that URL.
• Publish to OCI Object Storage as part of the product feed, with public or pre-authenticated URLs your team controls.
• Push into HubSpot's file store through the files API during the product sync. HubSpot returns a public URL and serves the image itself, and your network stays private.

The third needs no new public infrastructure on your side, which makes it our default recommendation; any of the three works.

The initial load (customer accounts and sales history) moves through HubSpot's imports API, which is built for exactly this purpose. We move the bulk of the data first as a pilot, verify it, and use it for your training, so the team learns on real records. At cutover we run a delta migration to catch everything that changed in between.

If it suits the rollout, the load can run in two stages: the boutiques first, around 16,000 contacts, with the larger EDM database following later. Once the interfaces are up, a second stage adds little cost or effort.

On limits: HubSpot's API allowances are generous, and the published numbers are in section 07 so your team can check headroom directly.

Every field keeps exactly one owner: your systems own identity and transactions, HubSpot owns consent and engagement. That prevents the two systems from overwriting each other.

Only currently subscribed contacts come in. From then on, HubSpot's preference centre and subscription types manage consent, and the moment someone opts out, a webhook tells Oracle so every channel respects it.

The same webhooks carry more than preferences. HubSpot fires on changes to all its primary objects, so new leads, contact enquiries and corrected details all stream back through the gateway. Your team builds the receivers; we document exactly what each webhook carries, and a change that originated in your systems is never echoed back at them.

The returning walk-in

The scenario Fiona raised: a customer leaves their details in a boutique today and returns tomorrow to buy. Their profile shouldn't need entering twice. The flow: the boutique form creates the contact in HubSpot immediately, HubSpot's webhook sends it to Oracle, and Oracle passes it down to Retail Express, fields permitting. That last hop is overnight today and near instant once your Retail Express APIs are live.

On the direct alternative, HubSpot writing straight to Retail Express: we have checked the published documentation. The v2.1 docs confirm customer reads but list write support resource by resource without naming customers; Retail Express's webstore service and several commercial connectors do create and update customers, so the capability exists. With Oracle in the middle, this remains a fallback rather than the plan, and the one remaining detail (which exact endpoint serves the write) only needs confirming if that option is ever required.

Capture in the boutique

A standalone landing page on a tablet in each boutique, styled to match your brand. A walk-in fills it in, a contact is created in HubSpot immediately, and the boutique is recorded with it. From there the automation runs: a follow-up email with the products they viewed, then a journey that adapts to their engagement. Customers expect something in return for their details, so the form is built around a clear value exchange, designed with Fiona.

The Seiko Club

A members' area on a subdomain of your site, served from HubSpot's Content Hub as private content. A member logs in and sees their own information: purchases wherever they happened, repair status, preferences they manage themselves, and collector content that gives them a reason to return. Templates stay editable by marketers, with drag-in modules for the dynamic pieces.

Today this kind of build sits with your creative agency, and whether it moves is an open decision. You'll have a scoped definition and a clickable mock up before you make it.

Authentication is a single private app access token sent as a Bearer header. Tokens don't expire on a schedule and can be rotated on demand, so there is no 60 minute refresh cycle to manage. Everything below is the current published surface your interfaces will touch.

Webhooks, the return direction

Your receivers subscribe to events such as object.creation and object.propertyChange on contacts, products and the custom record types. An opt out surfaces as a property change on the contact's hs_email_optout; that single subscription keeps Oracle's consent records accurate. One practical note for your team: on a standard private app, webhook subscriptions are configured in HubSpot's interface rather than by API. It takes minutes and isn't a blocker, but it's worth knowing in advance.

Published limits

Search has a separate limit of 5 requests per second. A single import file caps at 1,048,576 rows or 512 MB. Nothing discussed so far comes close to these limits.

Our read of the Retail Express documentation

For balance, the same diligence on the Retail Express side. The published documentation is solid on the basics: authentication (an API key exchanged for a Bearer token that expires every 60 minutes), the rate limits (300 requests a minute and 100,000 a day, shared across everything connected to your account), pagination, and read access to customers, orders and products.

It is thinner beyond that. Write support is documented resource by resource, with no published list of which resources accept writes; their own documentation notes that support 'will be improved over time'. The customer resource shows read operations only in the public material. No webhook or push mechanism is documented, and four legacy SOAP services (the webstore service among them) remain in use, with the REST API positioned to replace them over time. Small inconsistencies, such as the URL format differing between examples, suggest documentation that trails the product.

None of this is a blocker, and it is not a criticism of the platform; the API surface is still maturing, by their own description. It does support the architecture you've chosen. Your team's Retail Express interfaces stay internal, where you already know the system, and HubSpot never depends on Retail Express's public API directly. It is also why the direct write in section 05 is treated as a fallback rather than the plan.

Still open

The technical questions from the call are answered above: the endpoint map and limits are in section 07, the image options in section 03, and the Retail Express write question in section 05. Two items remain open.