HubSpot
Connect your HubSpot portal once, and the people who connect to your allme service become HubSpot contacts that keep themselves current — first name, last name, email, phone and address, plus anything else you ask for, written straight onto the contact record. One-way, consent-first, and no code.
What you need
- A HubSpot account you can grant an app access to. Any tier works — see Limits for what the free tier changes.
- An allus service is not something you create first: connecting from the portal creates it for you, together with its API client and its webhook.
Setting it up
The whole thing is two connections, in this order, both started from the allus portal — Configuration → Integrations. There is nothing to create or paste yourself: the portal provisions what this step needs behind the scenes.
- Connect allus. Click Connect next to HubSpot. The portal creates the service, publishes what it asks your customers for (first name, last name, email, phone, address), registers its API client and its webhook — sync alerts go to your allus account's own email — and hands you on to the next step.
- Connect HubSpot. One button, one HubSpot consent screen, and you are back on the status page. The connection asks for contact read/write and contact-schema read/write — the schema permissions are what let it create a property for anything you ask for beyond the five above.
You can leave and come back: the setup page resumes where it left off, and re-running it never creates a second service, client or webhook.
What lands where
Five fields map onto HubSpot's own contact fields. Everything else becomes a custom property named after the field, so nothing you ask for is silently dropped.
| What the customer shared | Where it lands in HubSpot |
|---|---|
| First name | firstname |
| Last name | lastname |
email | |
| Phone | phone |
| Address | address, city, state, zip, country |
| Anything else you request | a custom property, allme_<field> |
Every synced contact also carries allme share code (allme_id) — the durable link between that person and their HubSpot record. It is what lets an update find the right contact even if the email or phone later changes, so do not edit or clear it.
Country is stored as its two-letter ISO code (NL, DE, US), which is what the customer's own address carries. House number and any addition are joined onto the street line, because HubSpot has a single street field.
How an existing contact is found
The first time someone connects, the integration looks for a contact they already have in your portal, in this order: the allme_id share code, then email, then phone. A rung only counts when it matches exactly one contact — if two contacts share that email, it does not guess, and a new contact is created instead. A duplicate you can merge is a far better outcome than one person's details written onto somebody else's record.
Phone matching needs a number in international form, starting with +. A bare national number is not matched on, because the same digits belong to a different person in every country.
Staying current
- A customer edits a field → the mapped property is overwritten. allme is always the source of truth for a synced field; nothing reads back out of HubSpot.
- A customer withdraws a field → the property is emptied and a note records the withdrawal. No stale value is left behind.
- A customer disconnects → a note records it and the contact is left exactly as it is. Records are never deleted or blanked.
Notes are written once per event even if delivery is retried — a retry is deduplicated and never adds a second copy.
Documents and signed flows
A document your customer shares, updates, deletes, or signs, or a contract flow they complete, shows up as a note on their HubSpot contact — the same object regular update notes use, so nothing new to look for. Each note names the document (or the flow) and the date; a document also carries its kind, and a document that later changes status — signed, accepted, cancelled — gets a follow-up note saying so, including how and exactly when it was signed when that applies.
Limits worth knowing
- Custom properties on the free tier. HubSpot caps how many custom contact properties a free portal can hold. If it refuses to create one, your status page reports that field as rejected with HubSpot's own message. Free some room in HubSpot, or upgrade, and it resolves on the next sync.
- Request rate. HubSpot allows 110 requests per 10 seconds per portal and does not raise it. The integration paces itself well inside that and batches contact writes, so a bulk change does not exhaust the allowance you share with everything else connected to your portal.
- Contact lookups have their own, tighter limit. HubSpot counts searching for a contact separately from the allowance above and caps it per second. The integration paces its lookups against that limit specifically, so importing a long list of existing customers stays inside it and simply takes a little longer rather than being refused partway through.
- Timeline events. HubSpot's timeline API needs its own app-level setup that this integration does not use, so activity is written as notes on the contact rather than as custom timeline events.
Disconnecting
Disconnect from the status page. The webhook is deregistered first and the stored credentials are cleared; your HubSpot contacts are left untouched, including the properties already written. If the webhook cannot be deregistered nothing is cleared at all, and the page tells you so rather than leaving an endpoint behind that can no longer be verified.